Systems 

Network 

Architecture 


r i 

LJ 


w* 

M 




w'm 


Transaction Programmer 
Reference Manual For 
LU Type 6.2 



's 


GC30-3084-2 










































Systems 

Network 

Architecture 


Transaction Programmer 
Reference Manual For 
LU Type 6.2 


GC30-3084-2 

File No. 370/4300/8100-30 



Third Edition (November 1985) 


This edition* GC30-3084-2* is a major revision of the previous edition* GC30-3084-1* 
and obsoletes that edition* 

Changes are periodically made to the information in IBM systems publications. Before 
using this publication in connection with the operation of IBM systems* consult your 
IBM representative to find out which editions are applicable and current. For a sum¬ 
mary of the changes in this book* see page v. 

Any reference to an IBM program product in this document is not intended to state or 
imply that only IBM v s program product may be used. Any functionally equivalent pro¬ 
gram may be used instead. 

It is possible that this material may contain references to* or information about* IBM 
products (machines and programs)* programming* or services that are not announced in 
your country. Such references or information must not be construed to mean that IBM 
intends to announce such products* programming* or services in your country. 

This book is not intended for production use and is furnished as is. IBM assumes no 
responsibility for the use of the functions as described in this book in any pro¬ 
duction manner. 

Publications are not stocked at the address below; requests for IBM publications 
should be made to your IBM representative or to the IBM branch office serving your 
locality. 

A form for reader f s comments is provided at the back of this publication. If the form 
has been removed* comments may be addressed to IBM Corporation* Information Develop¬ 
ment* Department E02* P.0. Box 12195* Research Triangle Park* North Carolina 27709* 
U.S.A. IBM may use or distribute any of the information you supply in any way it 
believes appropriate without incurring any obligation whatever. You may* of course* 
continue to use the information you supply. 

@ Copyright International Business Machines Corporation 1982* 1983* 1985 


ii SNA Transaction Programmer’s Reference Manual for LU Type 6.2 



PREFACE 


This book presents detailed information on the functions that Systems 
Network Architecture (SNA) logical unit type 6.2 (LU 6.2) provides to 
system and application programs. This book is written for individuals 
that design system or application programs for use on an implementa¬ 
tion of LU 6.2. The information in this book applies to all IBM pro- 
| ducts that implement LU 6.2* not to any specific IBM product. 1 This 

book should be used with the applicable product publications for the 
IBM products that implement LU 6.2. 

LU 6.2 provides for interprogram communication between two or more 
programs* such that: 

• The programs can be distributed among multiple SNA nodes within an 
SNA network. 

• The SNA products that make up the network can be different from 
one another. 

• The programs r*r. be designed independently of where in the network 
they are located and of the SNA products on which they are run. 

This book describes the functions that allow programs to communica c ° 
with each other independent of the underlying SNA network configura- 
ti on. 

The processing of transactions typically involves several programs 
distributee; over a network communicating with each other. When used 
in conjunction with applicable IBM product publications* this book is 
especially useful to those who design transactions and the programs 
that process the transactions. 

This book assumes that the reader is familiar with the SNA concepts 
presented in Systems Network Architecture Concepts and Products * 
GC30-3072. The related publications* listed at the end of the pre¬ 
face* are also helpful in understanding the material in this book. 

The material in the first three chapters of this book is organized so 
that one may read the material straight through. Successive sections 
in these chapters build on the material presented in preceding 
sections. The material in the remaining chapters is organized for 
ease of reference. These chapters contain the detailed descriptions 
of the functions* called verbs * used to invoke LU 6.2 services. 


C HAPT E RS 


The chapters of this book are: 

"Chapter 1. Introduction" provides an introduction to LU type 6.2 and 
its services. 

"Chapter 2. LU 6.2 Protocol Boundary" presents a general description 
of the LU 6.2 protocol boundary. 

"Chapter 3. Transaction Program Verbs" gives an overview of the func¬ 
tions available to the programmer for interacting with resources. 


This book provides a general description of LU 6.2 functions. 
Implementation of some of the functions is optional. Optional 
functions may not be available on all IBM products that implement 
LU 6.2. All IBM products implementing a particular LU 6.2 func¬ 
tion provide that function as described in this book* however* the 
programming interface that a product provides to invoke that 
function may differ in syntax from the syntax represented in this 
book. 
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"Chapter 4. Conversation Verbs" contains a detailed description of 
the conversation verbs. 

"Chapter 5. Control-Operator Verbs" contains a detailed description 
of the control operator verbs. 


APPENDIXES 


The appendixes to this book are: 

"Appendix A. Base and Option Sets for Product Support" gives a break¬ 
down of the product-support requirements for implementing the verbs. 

"Appendix B. Examples Using Basic Conversation Verbs" provides exam¬ 
ples of the use of some of the basic conversation verbs. These are 
examples only; they represent no specific application. 

"Appendix C. Symbol String Conventions" defines the symbol strings 
referred to throughout the manual. 

"Appendix D. List of SNA Service Transaction Programs" contains a list 
of SNA service transaction programs. 

"Appendix E. Conversation State Matrices" provides matrix represent¬ 
ations of the state transitions and state-check conditions that occur 
at the conversation protocol boundary for programs using the basic and 
type-independent conversation verbs. 


PREREQUISITE PUBLICATION 

Systems Network Architecture Concepts and Products * GC3Q-3072 
RELATED PUBLICATIONS 

Systems Network Architecture Reference Summary * GA27-3136 

Systems Network Architecture Technical Overview * GC30-3D73 

S ystems Network Architecture Format and Protocol Reference Manual: 
Architecture Logic for LU Type 6.2 » SC30-3269. 

Systems Network Architecture Format and Protocol Reference Manual: 
Distribution Services * SC30-3098. 

Systems Network Architecture Format and Protocol Reference Manual: 
Architectural Logic # SC30-3112. 

Systems Network Archi tecture-^S ess i on s Between Logical Units * 
GC20-1868. 

Document Interchange Architecture; Technical Reference # SC23-0781. 

Document Interchange Architecture: Interchange Document Profjle_Ref- 
erence * SC23-0764. 

Document Interchange Architecture: Transaction Programmer's Guide # 
SC23-0763. 
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SM t fMA R Y, OF, AMENDMENTS 


This edition includes the following new functions* technical changes* 

and editorial changes: 

New Functions: 

• Session-level LU-LU verification has been added to LU 6.2 securi¬ 
ty. 

• The SECURITY_USER_ID and SECURITY_PROFILE parameters have been 
added to the MC_GET_ATTRIBUTES and GET_ATTRIBUTES verbs. 

• The MC_RECEIVE_IMMEDIATE and MC_TEST mapped conversation verbs 
have added. 

• The RECEIVE_IMMEDIATE and TEST basic conversation verbs have been 
added. 

• The CONFIRM argument has been added to the TYPE parameter of the 
MC_DEALLOCATE, MC_PREPARE_TO_RECEIVE, DEALLOCATE* and PRE- 
PARE_TO_RECEIVE verbs. 

• The DATA_TRUNCATED and FMHJDATA_TRUNCATED indications have been 
added to the WHAT_RECEIVED parameter of the MC_RECEIVE_AND_WAIT 
and MC_RECEIVE_IMMEDIATE verbs. 

• The FORCE parameter has been added to the RESET_SESSION_LIMIT 
verb. 

Technical Changes; 

• Conversation-level security has been enhanced for LU 6.2 securi¬ 
ty. 

• The definition of the base and option sets for product support of 
the verbs* parameter* return codes* and what-received indications 
has been changed. 

• The character set used for SNA-defined transaction program names 
has been changed. 

• The list of return codes for the MC_TEST* TEST* and WAIT verbs has 
been expanded. 

• The way in which the (LU*mode) session limit for single-session 
connections is specified on the INITIALIZE_SESSIGN_LIMIT verb has 
been changed. 

• The DEFINE and DISPLAY verbs have been expanded into a set of four 
DEFINE verbs and four DISPLAY verbs* and a DELETE verb has been 
added. 

Editorial Changes? 

• The material in this book has been reorganized: 

— The verb syntax diagrams have been modified to express cer¬ 
tain parameters as syntactically optional. 

— The mapped and basic conversation verbs have been combined 
into a single chapter* and the verbs that apply to both con¬ 
versation types have been sepa‘v*tsd Into their own section of 
the chapter. 

— The descriptions of the conversation states for all of the 
conversation verbs have been consolidated into one section of 
the chapter. 


Summary of Amendments 


v 




- The descriptions of the return codes for all of the conversa¬ 
tion verbs have been consolidated into one section of the 
chapter. 

— The base- and option-set definition for product support of 
all the verbs—conversation verbs and control operator 
verbs—has been consolidated into an appendix. 

• A clarification has been added to the list of product option sets 
to differentiate between those for which only local support is 
needed for their use# and those for which both local and remote 
support is needed. 

• A list is added showing the SNA-defined transaction program names 
assigned for use by LU 6.2 products. 

• A chart is added showing the hexadecimal codes for character sets 
A and AE. 

• An appendix has been added containing a matrix representation of 
the state transitions that occur at the conversation protocol 
boundary for programs using the basic and type-independent con¬ 
versation verbs. 

• Other less significant editorial improvements have been made. 


All these additions and changes# excluding the reorganization of 
material# are indicated in the left margin with a vertical line. 


vi 


SNA Transaction Programmer's Reference Manual for LU Type 6.2 



Chapter 1. introduction . 1-1 

Systems Network Architecture . 1-1 

Logical Unit Type 6.2 1-1 

Transaction Program . 1-1 

Protocol Boundary . 1-2 

Interprogram Communication . 1-3 

Chapter 2. LU 6.2 Protocol Boundary . 2-1 

Interprogram Communication . 2-1 

Protocol Boundary Structure . 2-2 

Chapter 3. Transaction Program Verbs . 3-1 

Transaction Program Structure and Execution . 3-1 

Verb Overview . 3-3 

Conversation Verbs . 3-3 

Mapped Conversation Verbs . 3-3 

Type-Independent Conversation Verbs . 3-4 

Basic Conversation Verbs . 3-5 

Control-Operator Verbs . 3-6 

Change Number of Sessions Verbs . 3-6 

Session Control Verbs . 3-7 

LU Definition Verbs . 3-7 

ABEND Conditions . 3-7 

Product-Support Subsetting . 3-8 

Verb Description Format . 3-9 

Chapter 4. conversation verbs . 4-1 

Verb Descriptions . 4-1 

Mapped Conversation Verbs . 4-2 

MC_ALLOCATE . 4-3 

MC.CONFIRM . 4-8 

MC_CONFIRMED . 4-10 

MC_DEALLOCATE . 4-11 

MC_FLUSH .4-15 

MC_GET_ATTRIBUTES . 4-16 

MC_POST_ON_RECEIPT . 4-18 

MC PREPARE.TO RECEIVE . 4-20 

MC_RECEIVE_AND_WAIT . 4-24 

MC_RECEIVE_IMMEDIATE . 4-29 

MC_REQUEST_TO_SEND . 4-34 

MC_SEND_DATA . 4-35 

MC_SEND_ERROR . 4-38 

MC_TEST .4-41 

Type-Independent Conversation Verbs . 4-44 

BACKOUT .4-45 

GET TYPE .4-46 

SYNCPT .4-47 

WAIT .4-50 

Basic Conversation Verbs . 4-52 

ALLOCATE .4-53 

CONFIRM .4-59 

CONFIRMED .4-61 

DEALLOCATE .4-62 

FLUSH .4-67 

GET_ATTRIBUTES . 4-68 

P0ST_0N_RECEIPT . 4-70 

PREPARE_TO_RECEIVE . 4-73 

RECEIVE_AND_WAIT . 4-77 

RECEIVE.IMMEDIATE .. . 4-82 

REQUEST_TO_SEND . 4-86 

SEND_DATA .4-87 

SEND_ERROR .4-90 

TEST .4-94 


Contents vii 































































Conversation States . 4-97 

Return Codes . 4-99 

Chapter 5. Control-Operator verbs . 5-1 

LU-LU Sessions . 5-1 

Single and Parallel Sessions . 5-1 

Contention-Winner Polarity. . 5-2 

Verb Descriptions . 5-3 

Change Number of Sessions Verbs . 5-4 

CHANGE_SESSION_LIMIT . 5-5 

INITIALIZE_SESSION_LIMIT . 5-8 

RESET_SESSION_LIMIT . 5-12 

PROCESS_SESSION_LIMIT . 5-16 

Session Control Verbs . 5-18 

ACTIVATE_SESSION . 5-19 

DEACTIVATE.SESSION . 5-21 

LU Definition Verbs . 5-22 

DEFINE_LOCAL_LU . 5-23 

DEFINE_REMOTE_LU . 5-26 

DEFINEJ10DE .5-30 

DEFINE_TP .5-34 

DISPLAY_LOCAL_LU . 5-40 

DISPLAY_REMOTE_LU . 5-42 

DISPLAYJ10DE .5-44 

DISPLAY_TP .5-47 

DELETE .5-49 

Return Codes . 5-51 


Appendix A. Base and Option Sets for Product support . . . A-l 

Support for Napped Conversation Verbs and Parameters .... A-5 

Support for Type-Independent Conversation Verbs and Parameters A-8 
Support for Basic Conversation Verbs and Parameters .... A-9 

Support for Conversation Return Codes and What-Received 

Indications .A-12 

Support for Control-Operator Verbs and Parameters for CNOS . A-14 

Support for Control-Operator Verbs and Parameters for Session 

Control .A-15 

Support for Control-Operator Verbs and Parameters for LU 

Definition .A-16 

Support for Control-Operator Return Codes . A-19 

Notes on Implementation Details . A-20 

Appendix B. Examples Using Basic conversation Verbs .... B-l 

Appendix c. symbol string conventions . C-l 

Symbol String Type .. C-l 

Symbol String Length . C-4 

Appendix D. List of SNA Service Transaction Programs . . . D-l 

SNA Service Transaction Program Names . D-l 

Scheduler . D-l 

Queue . D-l 

DL/1 . D-2 

Change Number of Sessions . D-2 

Resynchronization . D-2 

Distributed Data management . D-2 

Document Interchange Architecture . D-2 

SNA Distribution Services . D-2 

Product Oriented . D-2 

Appendix E. Conversation state Matrices . E-l 

index . x-1 


vi i i 


SNA Transaction Programmer's Reference Manual for LU Type 6.2 

















































LIST OF FIGURES 


Chapter 1. Introduction 

Figure 1-1. Transaction Programs and SNA Resources . . . 1-2 

Chapter 2. LU 6.2 Protocol Boundary 

Figure 2-1. Program-to-Program Connection Through the SNA 

Network . 2-1 

Figure 2-2. Effective Program-to-Program Connection . . . 2-2 

Figure 2-3. A Configuration of Interconnected Programs . 2-2 

Chapter 3. Transaction Program Verbs 

Figure 3-1. Format Box for Representing Verb Syntax . . . 3-10 

Chapter 4. Conversation Verbs 

Figure 4-1. Correlation of Conversation Verbs to the 

Conversation States Allowing Their Issuance • 4-98 

Figure 4-2. Correlation of Return Codes to Verbs . . . 4-105 

Chapter 5. Control-Operator Verbs 

Figure 5-1. Correlation of Return Codes to Verbs .... 5-54 

Appendix A. Base and option Sets for Product Support 

Figure A-l. Support for Mapped Conversation Verbs and 

Parameters (Part 1 of 3) . A-5 

Figure A-2. Support for Mapped Conversation Verbs and 

Parameters (Part 2 of 3) . A-6 

Figure A-3. Support for Mapped Conversation Verbs and 

Parameters (Part 3 of 3) . A-7 

Figure A-4. Support for Type-Independent Conversation Verbs 

and Parameters . A-8 

Figure A-5. Support for Basic Conversation Verbs and 

Parameters (Part 1 of 3) . A-9 

Figure A-6. Support for Basic Conversation Verbs and 

Parameters (Part 2 of 3) .A-10 

Figure A-7. Support for Basic Conversation Verbs and 

Parameters (Part 3 of 3) .A-ll 

Figure A-8. Support for Conversation Return Codes .... A-12 

Figure A-9. Support for Conversation What-Received 

Indications .A-13 

Figure A-10. Support for Control Operator Verbs and 

Parameters for CNOS .A-14 

Figure A-ll. Support for Control Operator Verbs and 

Parameters for Session Control . A-15 

Figure A-12. Support for Control Operator Verbs and 

Parameters for LU Definition (Part 1 of 3) . A-16 

Figure A-13. Support for Control Operator Verbs and 

Parameters for LU Definition (Part 2 of 3) . A-17 

Figure A-14. Support for Control Operator Verbs and 

Parameters for LU Definition (Part 3 of 3) . A-18 

Figure A-15. Support for Control Operator Return Codes . . A-19 

Appendix B. Examples Using Basic Conversation Verbs 

Figure B-l. ALLOCATE* SEND_DATA, DEALLOCATE -- 

SYNC_LEVEL(NONE) . B-2 

List of Figures ix 















Figure B-2. ALLOCATE, SEND_DATA, DEALLOCATE — 

SYNC_LEVEL(CONFIRM) . B-4 

Figure B-3. RECEIVE_AND_WAIT, DEALLOCATE — 

SYNC_L EVEL(CONFIRM) . B-6 

Figure B-4. PREPARE_TO_RECEIVE — SYNC LEVEL(NONE) ... B-8 

Figure B-5. PREPARE TO_RECEIVE — SYNC_LEVEL(CONFIRM) . . B-10 

Figure B-6. CONFIRM .B-12 

Figure B-7. SEND_ERROR in Send State .B-14 

Figure B-8. SEND_ERROR in Receive State . B-16 

Figure B-9. REQUEST_TO_SEND . B-18 

Figure B-10. P0ST_0N_RECEIPT, WAIT . B-20 

Figure B-ll. POST_ON_RECEIPT, TEST .B-22 

Figure B-12. SYNCPT . B-24 

Figure B-13. SYNCPT, BACKOUT . B-26 


Appendix C. Symbol String Conventions 

Figure C-l. Character Sets A and AE . C-2 

p :gure C-2. Symbol-String Types . C-3 

Figure C-3. Symbol-String Lengths . C-5 


Appendix D. List of SNA service Transaction Programs 


Appendix E. conversation state Matrices 

Figure E-l. Conversation State Transition Matrix (Part 1 of 

3) E-2 

Figure E-2. Conversation State Transition Matrix (Part 2 of 

3) E-4 

Figure E-3. Conversation State Transition Matrix (Part 3 of 

3) E-6 

Figure E-4. Conversation State Check Matrix . E-8 


x 


SNA Transaction Programmer's Reference Manual for LU Type 6.2 




















CHAPTER 1. INTRODUCTION 


This chapter introduces the reader to general concepts used through¬ 
out the book. 


SYSTEMS NETMORK^ARCHITECTURE 

Systems Network Architecture (SNA) is the description of the logical 
structure* formats* protocols* and operational sequences for trans¬ 
mitting information units through networks and for controlling the 
configuration and operation of networks. A formal description of SNA 
is provided in SNA Format and Protocol Reference Manual: Architec¬ 
tural Logic . The description of SNA in this book is limited to the 
services that SNA logical-unit type 6.2 (LU 6.2) provides to trans¬ 
action programs. A formal description of LU 6.2 is provided in SNA 
Format and Protocol Reference Manual: Architecture Logic for LU Type 
6 . 2 . 


LOGICAL UNIT TYPE 6.2 

In SNA* the physical network consists of actual processors* called 
nodes* and data links between the nodes. The logical network consists 
of logical processors* called logical units (LUs)* 1 and logical con¬ 
nections* called sessions. One or more sessions connect one LU to 
another LU. Information is transmitted from one LU to another LU over 
a session. 

LU 6,2 is a particular type of SNA logical unit. LU 6.2 provides a 
connection* or port* between its transaction programs and network 
resources. Each LU 6.2 makes a set of resources available to its 
transaction programs. The exact set is product- and 
configuration-dependent* examples are processor machine cycles and 
main storage* files on magnetic disk or tape* input/output devices 
such as keyboard and display terminals* and logical resources such as 
sessions* queues* and data-base records. Some of these resources are 
local to a program* that is* attached to the same LU as the program. 
Other resources are remote* that is* attached to other LUs (remote is 
defined in terms of the logical configuration of the network* the LUs 
can be within the same physical node). 

Resource allocation and control is a central function of LU 6.2, Pro¬ 
grams can request the LU for access to a resource. The LU schedules 
allocation to serially-reusable resources* creating new copies of 
logical resources* such as sessions* when necessary. The LU provides 
resource control in order to nsure integrity of the program's access 
to the resource. For example* the LU maintains a state 2 represen¬ 
tation of the resource* allowing the program to perform an operation 
on the resource only when the resource is in the appropriate state for 
that operation. The LU may also provide other resource-related serv¬ 
ices to its programs* such as resource synchronization-point process¬ 
ing that synchronizes committed changes to resources. 


IPms.ACX3LQliJBPP.BAi3 

Transaction programs process transactions. A transaction is a type of 
application. It usually involves a specific set of input data and 
triggers the execution of a specific process or job. One example is 


Other logical processors* such as physical units CPUs) and system 
services cc.ixrol points (SSCPs)* also exist and are described in 
SNA Concepts and Products . 

A specific operating condition of the resource as it appears to 
the program at a particular time of access. Over time* the 
resource changes from one state to another in accord with the pro¬ 
gram's operations on the resource. 
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the entry of a customer's deposit and the updating of the customer's 
balance. A second example is the process of recording item sales* 
arriving at the amount to be paid by or to a customer* verifying 
checks before accepting them as tender* and receiving payment for the 
merchandise. A third example is the transfer of a message to one or 
more destination points. 

A transaction program # as the term is used in this publication* is a 
program that is executed by or Mi thin LU 6.2 and performs services 
related to the processing of a transaction. For example* the program 
may be an application program that processes a transaction or is one 
of several programs that make up a transaction processing applica- 
tion* or it may be a system program that performs system services for 
an application program processing a transaction. 

Distributed processing of a transaction Mi thin an SNA netuork occurs 
Mhen transaction programs communicate by exchanging information over 
the sessions betMeen their LUs* treating the session as a resource 
that is shared betMeen the programs. Figure 1-1 illustrates the con¬ 
nection of tMO programs to SNA resources* including a session betMeen 
their LUs. 



Figure 1-1. Transaction Programs and SNA Resources 


The "other resources" shoMn in the figure may include other sessions 
as Mali as local files and devices. The other sessions alloM program 
A or program B to communicate Mith other programs. During the commu¬ 
nication betMeen tMO programs* one program may send a message over the 
session to another program* requesting access to a local resource of 
the other program. In this May* a local resource of program B* for 
example* may become a remote resource of program A. 


PROTOCOL BOUNDARY 

The LU 6.2 protocol boundary * as the term is used in this publication* 
is the generic description of the transaction program's logical 
interface to an SNA netMork* from the perspective of the transaction 
program; LU 6.2 provides the protocol boundary betMeen the program and 
the netMork. The description is generic in the sense that it provides 
a syntactical representation of the functions common to all IBM pro¬ 
ducts that implement LU 6.2* the syntactical description is not neces- 
■3ar_i. lv of any, specific IBM pro d uct . IBM products implementing LU 6.2 
may provide a programming interface that differs in syntax from the 
protocol boundary described herein* hoMever* the results achieved are 
functionally equivalent to the results described in this book. For 
information about the functional correspondence betMeen the product's 
programming interface and the protocol boundary described in this 
book* refer to the IBM product publication describing the product's 
programming interface. 
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The generic protocol boundary described herein represents the trans¬ 
action program's logical interface to SNA and its services* and is the 
primary subject of this book. The value of a generic description is 
that the transaction program designer may plan an application that 
spans many different products using a single generic interface* and 
then map the design to the individual product-dependent interfaces. 

Note: Products may provide additional functions for their trans¬ 
action programs* that is* product-uni que functions that are not 
described in this book. A given product-unique function may cause 
information to be sent on an LU 6.2 session* depending on the func¬ 
tion* however* the formats and protocols used on the LU 6.2 session 
are unchanged. (See SNA Format and Protocol Reference Manual: Archi¬ 
tecture logic for LU Type 6.2 for a definition of the formats and pro¬ 
tocols associated with LU 6.2 sessions.) When designing an 
application that may be executed on different products* the trans¬ 
action program designer should not depend on the product-specific 
functions being available across the different products. 


INTERPROGRAM COMMUNICATION 

Among the services that SNA and* in particular* LU 6.2 provides is 
interprogram communication. IBM products implementing LU 6.2 provide 
this service as Advanced Proqram-to-Program Communication (APPC). 
Refer to the individual IBM product publications for details of their 
APPC implementations. 

Interprogram communication permits distribution of the processing of 
a transaction among multiple programs within a network. The programs 
coordinate the distributed processing by exchanging control informa¬ 
tion or data. The protocol boundary provides the structure for pro¬ 
grams to communicate with one another in order to process a 
transaction. This structure meets the following requirements* 
described in terms of their SNA realization: 

Simultaneous activation — Many distributed applications require 
their component programs to be active simultaneously. If the 
sender of a request waits for the reply* the sending program is 
depending upon timely execution by its partner. SNA achieves this 
by simply carrying the program name in the request and letting the 
receiving LU create an instance of the desired partner program. 
This concept is recognizably that of transactions* so in SNA the 
communicating programs are called transaction programs. It fol¬ 
lows that distributed transactions are executed by distributed 
transaction programs. 

Efficient allocation — Just as programs use local resources by 
asking the LU for access to them* programs ask the LU for access 
to sessions for use as interprogram communication resources. 
However* the program is not really concerned with the session* 
which is (usually) a long-term connection between LUs. Nor is the 
program concerned with the possibility of other programs using 
the session before or after its own use. What the program asks 
the LU for is a period of exclusive use of a session* that is* for 
an abstract resource that is the unit of sharing of the session 
resource. This resource is called a conversation. 

Conversation overhead — Conversations should be efficient in 
allocation* data transfer* and deallocation. For instance* what 
the programs see as two short messages* perhaps an inquiry and its 
reply* should result in two short messages flowing in the network. 
The Lli achieves this by multiplexing conversations over a pool of 
sessions* scheduling each session as a serially reusable 
resource. 

Conversation lifetime — Conversations last for a time that is 
determined only by the communicating programs. So* conversations 
vary from a single* short message to many exchanges of long or 
short messages. A conversation could continue indefinitely* ter¬ 
minated only by failures. 

Two-way alternate data transfer — Conversations use two-way 
alternate (half duplex) data transfer. This makes it easier to 
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write transaction programs, in contrast to two-way simultaneous 
(full duplex) transfer of data which experience shows leads to 
more complicated and error-prone programs. 

Attention mechanism — Conversations include an attention mech¬ 
anism to handle asynchronous, but non-error, events. 

Error notification — Conversations provide each program with a 
method to notify its partner of errors when they are detected. 

Commitment control — When errors occur, recovery is greatly sim¬ 
plified if the changes that a program has been making to its 
resources can be made to appear atomic; for example, if resources 
A and B are changed, then after a failure, B will be observed to 
have changed if and only if A is also observed to have changed. 
Committing changes atomically is a service that SNA extends to 
distributed transaction programs. SNA calls this the sync point 3 
service. Conversations are defined to the sync point service in 
each LU as either being protected by sync point or as being unpro¬ 
tected. In the latter case, the transaction programs are them¬ 
selves responsible for error recovery synchronization. 

Symmetry — Conversations are allocated by one active program, 
but all other protocols (data transfer, attention, error notifi¬ 
cation, and deallocation) are fully symmetric. 

Node Of service — The program allocating the conversation names 
the desired mode of transmission service, such as "?nteractive" 
or "batch,” to be provided by the network. 

Levels Of conversations — In order to adequately serve the needs 
of system programs and application- transactions, two levels of 
conversations exist: basic conversations, for system transaction 
programs, and mapped conversations, for application transaction 
programs. 

Subset definition — A subsetting is defined for LU 6.2 by a base 
set of functions and a limited number of option sets. IBM pro¬ 
ducts that implement LU 6.2 all provide the base set of functions, 
and may provide any of the option sets. 


Sync point is a shortened term for synchronization point. 
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CHAPTER 2. LU 6.2 PROTOCOL BOUNDARY 


The LU 6.2 protocol boundary is a generic interface between trans¬ 
action programs and the SNA network. The protocol boundary permits 
access to SNA services and resources; especially the services and 
resources associated with interprogram communication. By means of 
interprogram communication# distributed transactions can be designed 
and implemented. 

The distributed processing of a transaction also requires access to 
system services and resources not related to interprogram communi¬ 
cation# however# such services and resources are product-dependent. 
The reader should refer to the individual product publications for 
information about a particular product's programming interface to 
resources such as disk or tape files# input/output devices# and 
processor main storage# and to non-SNA services that the product pro- 
vides. 


INTERPROGRAM COMMUNICATION 

The protocol boundary permits transaction programs to communicate 
with one another without being involved in the interactions that take 
place within the network. Figure 2-1 shows two programs connected 
through the SNA network. The LUs are connected by an LU-LU session# 
and the programs are connected by a conversation allocated on the ses¬ 
sion. For each LU-LU session# one LU is the contention winner of the 
session and the other LU is the contention l oser of the session. 
These terms relate to how contention is resolved when the two LUs 
attempt to allocate a conversation on the session at the same time. 
Specific details are given in SNA Format and Protocol Reference Manu¬ 
al: Architecture Logic for LU Type 6.2 . 



Figure 2-1. Program-to-Program Connection Through the SNA Network 


From the programs' view# only the conversation is visible. The acti¬ 
vation of the session and actual messages that the LUs exchange on 
that session are hidden from the programs. Only the delays associated 
with the buffering and transmission of information within the network 
are apparent to the programs. The program-to-program connection can 
therefore be represented as shown in Figure 2-2. 


Chapter 2. LU 6.2 Protocol Boundary 


2-1 











Program A 


Program B 


Figure 2-2. Effective Program-to-Program Connection 


This view of program-to-program connection can be extended to a more 
general configuration of interconnected programs. Figure 2-3 shows 
an example of one way in which seven programs can be interconnected. 
The interconnection is logical; the physical configuration' of the 
network is not apparent to the programs. 



Figure 2-3. A Configuration of Interconnected Programs 


The configuration of interconnected programs changes over time. In 
the example shown in Figure 2-3# the configuration may have evolved as 
follows: 

1. Program A connects to Program B# then to Program C# and then to 
Program D. 

2. Program B connects to Program E and then to Program F. 

3. Program D connects to Program G. 

This configuration may have evolved in other ways# as well# and it may 
be an interim configuration that ultimately grows to a much larger 
configuration of interconnected programs. All configurations of 
interconnected programs# however large# are made up of program-to- 
program connections between pairs of programs. One program initiates 
the interconnection process# in Figure 2-3# the initiating program is 
Program A. 


PROTOCOL BOUNDARY STRUCTURE 

The protocol boundary is a structured interface. It is defined by 
means of formatted functions# called verbs # and the protocols for the 
verbs. The protocols are the allowed sequences of verbs# that is# the 
order in which a transaction program can issue verbs. The protocols 
are defined in terms of resource states . A transaction program can 
issue a particular verb only when the the resource to which that verb 
applies is in the appropriate state for that verb. 
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The verbs end states that represent the LU 6.2 protocol boundary ena¬ 
ble the user to design distributed transactions* processed by dis¬ 
tributed transaction programs. The number of transaction programs 
can be small* involving only two programs* or large* involving many 
programs. The transaction can have a fixed structure in which the 
processing by all programs is predetermined at design time* such as a 
single inquiry and reply between two programs. In contrast* the 
transaction can have a flexible structure in which the programs 
involved and the processing are determined at execution time* possi¬ 
bly varying from one invocation of the transaction to the next; an 
example is the updating of information in a distributed data base. 

An overview description of the verbs is given in "Chapter 3. Trans¬ 
action Program Verbs". The detailed descriptions of the verbs are 
given in "Chapter 4. Conversation Verbs" and "Chapter 5. 
Control-Operator Verbs". Resource states associated with the conver¬ 
sation verbs are described in "Chapter 4. Conversation Verbs". 


Chapter 2 
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CHAPTER 3. TRANSACTION PROGRAM VERBS 


The LU 6.2 protocol boundary is defined by verbs that request the LU 
to perform services. The verbs are described from the transaction 
programmer’s view of the LU 6.2 protocol boundary. Events occurring 
below the protocol boundary and not apparent at the boundary are not 
described. Refer to SNA Format and Protocol Reference Manual: Archi¬ 
tecture Logic for LU Type 6.2 for details of events that occur below 
the protocol boundary. 


TRANSACTION PROGRAM STRUCTURE AND EXECUTION 

All transaction programs have the following general structure: 


name: PROCEDURE ( resource-id [»pipl If... I#pipn] ] I ); 




r verbs and other program statements 


RETURN; 
END name; 


The elements of the transaction program structure are: 

name is the name of the transaction program. The transaction pro¬ 
gram name is carried in the allocation request sent by a partner 
program. The LU receiving the request locates the program by name 
and creates a new instance# 1 or executable copy# of the program. 
The location of the program# such as in a program library# is 
product-dependent. 

PROCEDURE begins the main procedure of the transaction program. 

resource-id is the name of the variable in which the LU places the 
resource ID of the conversation on which the allocation request 
was received. The conversation connects this transaction program 
to the partner program that sent the allocation request. 

Note: The description in this book assumes that transaction pro¬ 
grams are always started by means of an allocation request 
received on a conversation. The manner in which a product starts 
the first program of an interconnected configuration of programs 
is product-dependent. For example# the first program may be 
started in response to a "load” request from an operator. 

piplf • • • #pipn are the names of the variables in which the LU 
places program initialization parameters (PIPs) 1 through n. 
Product send and receive support of PIPs is optional# see Fig¬ 
ure C-3 in "Appendix C. Symbol String Conventions" for details. 
The PIPs are supplied by the allocating program. The contents of 
the PIPs have meaning only to the transaction programs—they are 
not examined or acted upon by the LU. 

verbs and other program statements represent the combination of 
verbs# described in this book# and other programming-language 
statements that make up the transaction-processing portion of the 
program. Thus# the program’s processing of a transaction begins 


When it is "^ambiguous to do so# a program instance is simply 
referred to as a program. 
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with the first verb or other program statement after the PROCEDURE 
statement. It ends with the last verb or other program statement 
preceding the RETURN statement# or with the processing implied by 
the RETURN statement (discussed next). 

RETURN ends execution of the program by returning control to the 
LU. As part of the LU's processing of the RETURN statement# it 
deallocates all conversations (and other resources) that the pro¬ 
gram has not# itself# deallocated. Depending on the product# the 
LU may perform other resource-related functions# including the 
execution of verb functions for conversations still allocated# 
before deallocating the resources. 

END name identifies the physical end of the program. It is the 
last statement in the program. 

Note: The PROCEDURE, RETURN# and END statements are not 
described elsewhere in this book. They are presented here only to 
illustrate the general structure of all transaction programs. 
IBM products implementing LU 6.2 may provide programming language 
statements that differ in syntax from this description. However# 
the functions of the product programming language statements are 
equivalent to the functions described here. 

Program execution# in terms of the verbs# occurs when the transaction 
program i ssues a verb and the LU executes it# verbs are issued and 
executed one at a time. Uhen the program issues a verb# the program's 
processing is suspended while the LU executes the verb. The program 
resumes processing when the LU returns control to the program. The 
program may then issue another verb. 

Conversations use two-way alternate data transfer. Once a conversa¬ 
tion is allocated# send-receive relationship is established between 
the programs connected to the conversation. One program issues verbs 
to send data and the other program issues verbs that receive the data. 
Uhen the sending program finishes sending data# it transfers control 
of sending data to the other program. 

The LUs at each end of a conversation have a buffer for sending and 
receiving the data on the conversation. Uhen the program issues a 
verb that sends data# it specifies an area containing the data. The 
LU moves the data to its send buffer * accumulating the data behind any 
data from previous verbs. The LU transmits the data# or flushes its 
send buffer# when either it accumulates a sufficient amount for trans¬ 
mission# or the program issues a verb that explicitly causes the LU to 
transmit the accumulated data. The amount of data sufficient for 
transmission is determined by the maximum size request unit that can 
be sent on the session on which the conversation is allocated. The 
amount can vary from one session to another# and therefore from one 
conversation to another. 

As incoming data arrives on a conversation# the LU places the data in 
its receive buffer # accumulating the data behind any it previously 
received. Uhen the program issues a verb that receives data# it spec¬ 
ifies an area in which the LU i s to place the data. The LU moves the 
requested amount of data from the front of its receive buffer to the 
area specified by the program. In this way# the LU can accumulate 
incoming data in its receive buffer in advance of the program issuing 
the verb# or verbs# that receive the data. 

Verbs are defined that send information other than data. These verbs 
cause the LU to flush its send buffer and then place the information 
at the front of the buffer# behind which it accumulates data from sub¬ 
sequent verbs. The receiving LU accumulates this information in its 
receive buffer in the order it is received# with reference to other 
information including data. 

Program execution ends when the program returns control to the LU at 
the completion of the transaction. This is accomplished by the RETURN 
statement. 
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VERB OVERVIEM 


This section presents an overview of the verbs in terms of their indi¬ 
vidual functions. The verbs are divided into categories. These cate¬ 
gories are: 

Conversation verbs 

Control-operator verbs 

Each category defines a major subdivision of the LU 6.2 protocol 
boundary. The conversation verbs define the means for program-to- 
program communication. The control-operator verbs define the means 
for program or operator control of the LU f s resources. 

In the following overview# and in the remaining chapters of this book# 
the verbs are described from the perspective of the transaction pro¬ 
gram issuing the verb. From this point of view# the program issuing 
the verb is referred to as the local program , and the program at the 
other end of the conversation is referred to as the remote program . 
Similarly# the LU processing the local program is referred to as the 
local LU * and the LU processing the remote program is referred to as 
the remote LU . a The overview description of the conversation verbs and 
control-operator verbs follows. 


CONVERSATION VERBS 

The conversation verbs provide program-to-program communication by 
means of conversations between programs. The following conversation 
types are defined: 

Mapped 
Basi c 

The verbs defining the conversation protocol boundary are divided 
into subcategories based on the conversation type. The subcategories 
of verbs are: 

Mapped conversation verbs 

Type-independent conversation verbs 

Basic conversation verbs 

An overview of the conversation verbs follows. 


Mapped Conversation Verbs 

The mapped conversation verbs are intended for use by application 
transaction programs. These verbs provide functions that are suit¬ 
able for application programs written in high-level programming lan¬ 
guages. A brief description of the mapped conversation verbs follows. 

MC_ALLOCATE allocates a mapped conversation connecting the local 
transaction program to a remote transaction program. A unique 
resource ID is assigned to the mapped conversation. This verb is 
issued prior to any verbs that refer to the mapped conversation. 

MC_CONFIRM sends a confirmation request to the remote transaction 
program and waits for a reply# in order for the two programs to 
synchronize their processing. 

MC_CQNFIRMFD sends a confirmation reply to the remote transaction 
Program# in order for the two programs to synchronize their proc¬ 
essing. The program issues the verb in response to receiving a 
confirmation request. 

MC_DEALLQCATE deallocates a mapped conversation resource from the 
transaction program. The program issues this verb when it is fin¬ 
ished using the mapped conversation. 


When it is unambiguous to do so# the local program is simply 
referred to as the program# and the local LU is simply referred to 
as the LU. 
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MC_FLUSH transmits all information that the LU has buffered* such 
as data records from preceding MC_SEND,J)ATAs. 

MC_GET_ATTRIBUTES returns information pertaining to a mapped con¬ 
versation. Examples of information that may be requested are the 
mode name* the name of the LU at which the remote transaction pro¬ 
gram is located* or the synchronization level allocated for the 
mapped conversation. 

MC_POST_ON_RECEIPT requests posting of the specified mapped con¬ 
versation when information is available for the program to 
receive. The information can be a data record* mapped conversa¬ 
tion status* or a request for confirmation or sync point. 

MC_PREPARE_TO_RECEIVE changes the mapped conversation from send 
state to receive state in preparation to receive data. A SEND 
indication is sent to the remote program. The remote program's 
end of the mapped conversation changes to send state when the pro¬ 
gram receives the SEND indication. 

MC_RECEIVE_AND_UAIT waits for information to arrive on the mapped 
conversation and then receives the information. If information 
is already available* the program receives it without waiting. 
The information can be a data record* mapped conversation status* 
or a request for confirmation or sync point. Control is returned 
to the program with an indication of the type of information. The 
verb can be issued when the mapped conversation is in send state. 
In this case* the verb first sends a SEND indication to the remote 
program* changing the mapped conversation to receive state* and 
then waits for information to arrive. 

MC_RECEIVE_IMMEDIATE receives any information that is available 
from the specified mapped conversation* but does not wait for 
information to arrive. The information (if any) can be a data 
record* mapped conversation status* or a request for confirmation 
or sync point. Control is returned to the program with an indi¬ 
cation of whether any information was received and* if so* the 
type of information. 

MC_REQUEST_TO_SEND notifies the remote program that the local 
program is requesting to enter send state for the mapped conversa¬ 
tion. The mapped conversation will be changed to send state when 
the local program subsequently receives a SEND indication from 
the remote program. 

MC_SEND_DATA sends one data record to the remote transaction pro¬ 
gram. The data record consists entirely of data. The program can 
specify data mapping as a function of the verb* or it can indicate 
that the data record includes FM headers. 

MC_SEND_ERROR informs the remote transaction program that the 
local program has detected an application error. For example* the 
local program can issue this verb to inform the remote program of 
an error it detected in a data record it received* or to reject a 
confirmation request. Upon successful completion of the verb* 
the local program is in send state for the mapped conversation and 
the remote program is in receive state. 

MCJTEST tests the mapped conversation to determine whether it has 
been posted* as a result of a preceding MC_POST_ON_RECEIPT verb* 
or whether a request-to-send notification has been received. 


Type-Independent Conversation Verbs 

The type-independent conversation verbs are intended for use with 
both mapped and basic conversations. These verbs provide functions 
that span both conversation types. A brief description of the 
type-independent verbs follows. 

BACKOUT restores all protected resources throughout a distributed 
transaction to their status as of the last synchronization point. 
Protected resources are those that are protected by the sync point 
service of LU 6.2. 
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GET_TYPE returns the type of resource. For mapped conversations 
the type is MAPPED_CONVERSATION, and for basic conversations the 
type is BASIC_CQNVERSATION. 

SYNCPT advances all protected resources throughout a distributed 
transaction to the next synchronization point. 

WAIT waits for posting to occur on any mapped or basic conversa¬ 
tion from among a list of mapped and basic conversations. The 
posting of mapped conversations is performed as a result of a pre¬ 
ceding MC_POST_ON_RECEIPT verb issued for each of the mapped con¬ 
versations. Similarly, the posting of basic conversations is 
performed as a result of a preceding POST_GN_RECEIPT verb issued 
for each of the basic conversations. 


Basic conversation Verbs 

The basic conversation verbs are intended for use by LU services pro- 
grams. The LU services programs can provide end-user services or pro¬ 
tocol boundaries for end-user application transaction programs. For 
example, the mapped conversation LU services component issues basic 
conversation verbs during its processing of mapped conversation 
verbs. A brief description of the basic conversation verbs follows. 

ALLOCATE allocates a conversation connecting the local trans¬ 
action program to a remote transaction program. The conversation 
type can be basic or mapped. A unique resource ID is assigned to 
the conversation. This verb is issued prior to any verbs that 
refer to the conversation. 

CONFIRM sends a confirmation request to the remote program and 
waits for a reply, in order for the two programs to synchronize 
their processing. 

CONFIRMED sends a confirmation reply to the remote program, in 
order for the two programs to synchronize their processing. The 
program issues this verb in response to receiving a confirmation 
request. 

DEALLOCATE deallocates a conversation from the transaction pro¬ 
gram. The program issues this verb when it is finished using the 
conversation. 

FLUSH transmits all information that the LU has buffered, such as 
data from preceding SEND^DATAs. 

GET_ATTRIBUTES returns information pertaining to a conversation. 
Examples of information that may be requested are the mode name, 
the name of the LU at which the remote transaction program is 
located, or the synchronization level allocated for the conversa¬ 
tion. 

POST_ON_RECEIPT requests posting of the specified conversation 
when information is available for the program to receive. The 
information can be data, conversation status, or a request for 
confirmation or sync point. 

PREPARE_TO_RECEIVE changes the conversation from send state to 
receive state in preparation to receive data. A SEND indication 
is sent to the remote program. The remote program’s end of the 
conversation changes to send state when the program receives the 
SEND indication. 

RECEIVE_AND_UAIT waits for information to arrive on the conversa¬ 
tion and then receives the information. If information is already 
available, the program receives it without waiting. The informa¬ 
tion can be data, conversation status, or a request for confirma¬ 
tion or sync point. Control is returned to the program with an 
indication of the type of information. The verb can be issued 
when the conversation is in send state. In this case, the verb 
first sends a SEND indication to the remote program, changing the 
conversation to receive state, and then waits for information to 
arrive. 
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RECEIVE_IMMEDIATE receives any information that is available from 
the specified conversation* but does not wait for information to 
arrive. The information (if any) can be data* conversation sta¬ 
tus* or a request for confirmation or sync point* Control is 
returned to the program with an indication of whether any informa¬ 
tion was received and* if so* the type of information. 

REQUEST_JO_SEND notifies the remote program that the local pro¬ 
gram is requesting to enter send state for the conversation. The 
conversation will be changed to send state when the local program 
subsequently receives a SEND indication from the remote program. 

SEND_DATA sends data to a remote program. The data format con¬ 
sists of logical records. The amount of data is specified inde¬ 
pendently of the data format. A logical record contains a length 
field and a data field. The length field is 2 bytes long* the 
data field can be any length within the range of 0 to 32765 bytes. 

SEND_ERROR informs the remote program that the local program has 
detected an error. For example* the local program can issue this 
verb to truncate an incomplete logical record it is sending* to 
inform the remote program of an error it detected in data it 
received* or to reject a confirmation request. Upon successful 
completion of the verb, the local program is in send state for the 
conversation and the remote program is in receive state. 

TEST tests the conversation to determine whether it has been 
posted* as a result of a preceding POST_ON_RECEIPT verb* or wheth¬ 
er a request-to-send notification has been received. 


CONTROL-OPERATOR VERBS 

The control-operator verbs are intended for use by control-operator 
transaction programs* that is* programs that assist the control oper¬ 
ator in performing functions related to the control of an LU. The 
verbs defining the control-operator protocol boundary are divided 
into subcategories based on their functions. The subcategories are: 

Change number of sessions verbs 
Session control verbs 
LU definition verbs 

An overview of the control-operator verbs follows. 


Change Number of Sessions Verbs 

This subcategory of control-operator verbs consists of four verbs 
called the change-number-of-sessions* or CNOS, verbs. The CNOS verbs 
change the (LU*mode) session limit* which controls the number of LU-LU 
sessions per mode name that are available between two LUs for allo¬ 
cation to conversations. In conjunction with changing the (LU*mode) 
session limit* the CNOS verbs change related operating parameters of 
the two LUs. 

The two LUs may cooperate in the execution of the CNOS verbs by means 
of a CNOS request and CNOS reply. The LU executing the control-opei— 
ator transaction program sends a CNOS request to the partner LU. The 
partner LU invokes an SNA service transaction program called the ”CN0$ 
service transaction program” (see "Appendix D. List of SNA Service 
Transaction Programs”)* which causes the partner LU to process the 
CNOS request and send back a CNOS reply. 

The CNOS verbs that a control-operator transaction program may issue 
are: 


CHANGE_SESSIONJ.IMIT changes the (LU*mode) session limit from one 
nonzero value to another nonzero value. 

INITIALIZE_SESSION_LIMIT changes the (LU*mode) session limit from 
0 to a value greater than 0. 
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RESET_SESSION_LIMIT changes the (LU*mode) session limit from a 
value greater than 0 to 0. 

The CNOS verb that the CNOS service transaction program issues is: 

PROCESS_SESSXON_LXHIT causes the LU receiving the CNOS request to 
process the request and send back a CNOS reply to the partner LU. 


Session Control Verbs 


This subcategory of control-operator verbs consists of two verbs used 
for session control* one that activates an LU-LU session and one that 
deactivates an LU-LU session. These verbs are: 

ACTIVATE_SESSXON activates an LU-LU session between the local LU 
and a specified LU. 

DEACTXVATE_SESSION deactivates a specified LU-LU session. The 
type of deactivation can be cleanup or normal. 


LU Definition Verbs 

This subcategory of control-operator verbs is used to define or modify 
the local LU v s operating parameters* examine the parameters* and 
delete the parameters. These verbs are: 

DEFINE_LOCAL_LU initializes or modifies parameter values that 
control the operation of the local LU. 

DEFINE_REMOTE_LU initializes or modifies parameter values that 
control the operation of the local LU in conjunction with a remote 
LU. 

DEFXNE_MODE initializes or modifies parameter values that control 
the operation of the local LU in conjunction with a group of ses¬ 
sions with a remote LU* the group being identified by a mode name. 

DEFINE_TP initializes or modifies parameter values that control 
the operation of the local LU in conjunction with a local trans¬ 
action program. 

DX$PLAY_J.OCAL_LU returns parameter values that control the opera¬ 
tion of the local LU. 

DISPLAY_REMOTE_LU returns parameter values that control the oper¬ 
ation of the local LU in conjunction with the remote LU. 

DXSPLAY_MODE returns parameter values that control the operation 
of the local LU in conjunction with a group of sessions with a 
remote LU* the group being identified by a mode name. 

DISPLAY_TP returns parameter values that control the operation of 
the local LU in conjunction with a local transaction program. 

DELETE deletes the local LU*s operating-parameter values that 
have been defined by means of the DEFINE verbs. 


ABEND CONDITIONS 


Certain errors related to the execution of the verbs can cause an 
abnormal ending (ABEND) of the transaction program. These ABEND con¬ 
ditions are a direct consequence of an invalid specification or exe¬ 
cution of a verb, blhen the LU terminates a program because of an 
ABEND condition* it deallocates all of the program f s active conversa¬ 
tions. Depending on the product* the LU may abnormally deallocate the 
conversations* or deallocate the conversations in the same way it does 
for the RETURN statement (see the RETURN statement under "Transaction 
Program Structure and Execution" on page 3-1). 

The ABEND conditions are: 


Chapter 3. Transaction Program Verbs 


3-7 



Parameter Check occurs Mhen the program issues a verb for which 
local support is not available, or when the program specifies a 
verb parameter with an invalid argument. The source of the inval¬ 
id argument is considered to be part of the program definition. 
(Contrast this definition with the definition of the return code, 
PARAMETER_ERROR, in the section "Return Codes" in Chapter 4.) The 
detailed verb descriptions list the applicable parameter checks. 

The omission of a required parameter, the specification of an 
undefined parameter, and the specification of an undefined argu¬ 
ment on a parameter that requires one of a defined set of keywords 
are also parameter check conditions. The parameter checks for the 
omission of a required parameter and for the specification of an 
undefined parameter apply to all verbs. The parameter check for 
an undefined keyword argument applies to all verbs that specify 
one or more parameters with keyword arguments. These parameter 
checks are not explicitly listed with each detailed verb 
description. 

State Check occurs when the program attempts to issue a verb for a 
conversation that is in a state in which the verb is not allowed. 
The section "Conversation States” in Chapter 4 defines the allow¬ 
able states for each conversation verb. The control-operator 
verbs do not have states associated with them and therefore do not 
have any state checks defined. 

The individual verb descriptions list the applicable ABEND condi¬ 
tions. 

Note: In lieu of treating these ABEND conditions as described here, 
products may provide a different method for handling the ABEND condi¬ 
tions. For example, a product may return'an error indication to the 
program when it attempts to issue a verb in a state in which the verb 
is not permitted* allowing the program to continue processing, or a 
product may provide a compile-time check for the specification of 
optional verbs and parameters that the product does not support. 
Refer to the individual product's publications for details about how 
it treats these conditions. 


PRODUCT-SUPPORT SUBSETTING 

Product-support subsetting of the verbs is defined by means of func¬ 
tional groups, or sets . A set consists of all the functions that 
together represent an indivisible group for products to implement. 
That is, a product implementing a particular set implements all of the 
functions within that set. 

All products implement a subset of LU 6.2 functions called the base 
set. The functions that are not part of the base set are optional. 

The base set and option sets are defined in terms of the LU 6.2 proto¬ 
col boundary, as follows: 

Base set is the set of LU 6.2 verbs, parameters, return codes, and 
what-received indications that all products support. 

Option sets are the sets of LU 6.2 verbs, parameters, return 
codes, and what-received indications that a product may support, 
depending on the product. A product may support any number of 
option sets, or none. For each option set supported, all verbs, 
parameters, return codes, and what-received indications in that 
set are supported. 

The base set and option sets are further defined in terms of local 
support and remote support. 

Local support is the support of LU 6.2 verbs, parameters, return 
codes, and what-received indications that the product provides at 
the local end of a conversation, as seen by the local transaction 
program. The program may issue an optional verb or parameter only 
when the local product supports the option set. An attempt by the 
program to issue an optional verb or parameter for which local 
support is not available is considered an ABEND condition (see 
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"ABEND Conditions" on page 3-7). An optional return code or 
what-received indication can be reported to the program only when 
the local product supports the option set. 

Remote support is the support of verbs and parameters that the 
product provides at the remote end of a conversation, as seen by 
the local transaction program. (Remote support does not apply to 
the return codes and what-received indications.) Only certain 
verbs and parameters invoke processing at the remote end of the 
conversation; the other verbs and parameters are processed 
entirely at the local end of the conversation. kJhen the program 
issues a verb or parameter that invokes remote processing, and the 
remote product does not provide remote support for the verb or 
parameter, a return code indicating the lack of support is 
reported to the program. The return code can be reported on the 
verb for which remote support is not available or on a later verb, 
depending on the verb. 

The base and optional support for the conversation verbs and control- 
operator verbs is defined in "Appendix A. Base and Option Sets for 
Product Support”. 

Note: The base- and option-set definition for product support 
described in this book applies only to LU 6.2 products that provide an 
application programming interface (API) for user-written programs 
that is equivalent to the conversation verbs. The definition does not 
apply to LU 6.2 products that are not user-programmable, or to pro¬ 
ducts that are user-programmable but do not provide an API equivalent 
to the conversation verbs; such products need support only the LU 6.2 
functions required for their applications. 


VERB DESCRIPTION FORMAT 

This section explains the format used to describe the verbs in the 
following chapters. The verb descriptions are presented alphabet¬ 
ically, by name, in terms of each verb’s function, syntactic format, 
parameters, state changes, ABEND conditions, and usage notes. 

The description of each verb begins with a brief explanation of its 
function. 

The verb's syntax is described next using a format box. The general 
representation of the format box is shown in Figure 3-1 on page 3-10. 
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Supplied Parameters: 

verb-name 

parameter ( argument ) 


parameter ( argument ) 

( argument ) 


parameter ( argument argument ... argument ) 


£ parameter ( argument ) J 


parameter ( default-araument ) 

1 ( argument ) 


SuppI ied-and-Returned Parameters: 


parameter ( argument ) 


Returned Parameters: 


parameter ( argument ) 


£ parameter ( argument ) j 

1 

# 


Figure 3-1. Format Box for Representing Verb Syntax 


As shown in the preceding general format box# the syntax description 
for each verb includes a verb name# verb parameters# and the ending 
delimiter "#" (semicolon). The number of verb parameters depends on 
the verb# and a verb may not have any parameters. 

Parameter names are shown as uppercase keywords. Parameter arguments 
are shown as uppercase keywords# as "variables#” or as a combination 
of keywords and "variables." An argument keyword is used to show a 
specific argument value associated with the parameter. An argument 
"variable" is used to show that the argument value can vary# it can be 
program data# for example. 

Some parameters show a vertical list of argument keywords (possibly 
combined with "variables"). The vertical list means the arguments are 
limited to those within the list# one of which is specified when the 
verb is issued. Other parameters show an argument list as "variablel 
... variablen." The number of arguments in the argument list depends 
on the verb; the number may be constant or it may vary from one issu¬ 
ance of the verb to the next. 

The parameters are grouped as "supplied parameters#" 
"supplied-and-returned parameters," or "returned parameters." 

• Supplied parameters contain arguments whose values are supplied 
by the program when it issues the verb. 

• Supplied-and-returned parameters contain arguments whose values 
are supplied by the program when it issues the verb and whose val¬ 
ues are returned to the program when it resumes processing. 

• Returned parameters contain arguments whose values are returned 
to the program when it resumes processing. 

Some parameters are shown within brackets. The bracket notation is 
used to show which parameters may be omitted when the verb is issued. 
It it also used for cross-publi cat i on reference purposes# so that oth- 


3-10 


SNA Transaction Programmer’s Reference Manual for LU Type 6.2 




er SNA and product publications that re*«r to the verbs in this book 
may omit references to the bracketed parameters. In particular: 

• Some bracketed supplied parameters have multiple arguments with 
one being a default argument* shown as underscored. Omission of 
any of these parameters is treated as if the default argument 
specified on the parameter. 

• Other bracketed supplied parameters have no default argument. 
Omission of any of these parameters is treated as described for 
the parameter. 

• If a bracketed returned parameter is omitted* the argument value 
is not returned. 

Following the syntax is a description of the verb’s parameters. 
Included is a list of the return codes that can be returned to the 
transaction program when it resumes processing. 

The changes* if any* to the state of the conversation at the protocol 
boundary are described next. The state changes occur as a result of 
executing the verb. 

After the description of state changes* the ABEND conditions are given 
for each verb. 

Finally* notes are given to describe certain aspects of the verb's 
usage in order to further clarify the actions of the verb. 

Notes: 

1. Products may provide application programming interfaces (APIs) 
that differ from the verb syntax described in this book. For 
example* a product may have different names for operations that 
are equivalent to the verbs and parameters described herein* it 
may combine the functions of certain verbs into one operation* 
such as the functions of MC_SEND_DATA and MC_CONFIRM; and it may 
separate the functions of a single verb into distinct operations* 
such as separating the functions of MC_ALLOCATE into an operation 
that acquires the session and an operation that allocates the con¬ 
versation on the session* These are syntactical* not functional* 
differences. 

2. The bracket notation used in the syntax diagrams is unrelated to 
the product-support subsetting described in this book. See 
"Product-Support Subsetting" on page 3-8 and "Appendix A. Base 
and Option Sets for Product Support" in Appendix A for details 
about product support. The bracket notation is also unrelated to 
any product's API definition. The product may allow a different 
set of parameters to be omitted* if any* and have different 
defaults for the supplied parameters. Refer to the product's pro¬ 
gramming publications for details of its API. 
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CHAPTER 4. CONVERSATION VERBS 


This chapter describes the category of verbs called conversation 
verbs . The conversation verbs define the LU 6.2 conversation protocol 
boundary. These verbs are used for program-to-program communications 
over a conversation connecting two programs. Each conversation is of 
a specific type: 

Happed 
Basi c 

The conversation verbs are divided into subcategories, based on the 
conversation type to which they apply: 

Happed conversation verbs 
Type-independent conversation verbs 
Basic conversation verbs 

The mapped conversation verbs apply to mapped conversations. The 
type-independent conversation verbs apply to both mapped and basic 
conversations. The basic conversation verbs apply to basic conversa¬ 
tions, and to mapped conversations for use by the mapped conversation 
LU services component. Refer to SNA Format and Protocol Reference 
Hanual: Architecture Logic for LU Type 6.2 for a description of the 

mapped conversation LU services component. 

Following the descriptions of the conversation verbs is a description 
of conversation states that allow issuance of the verbs, and a 
description of the return codes that apply to the conversation verbs. 


VERB DESCRIPTIONS 

The detailed descriptions of the mapped, type-independent, and basic 
conversation verbs follow. 
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HAPPED CONVERSATION VERBS 


This section describes the subcategory of conversation verbs called 
mapped conversation verbs . These verbs are intended for use by appli¬ 
cation transaction programs. They provide functions# such as data 
mapping (a product option)# that make the verbs suitable for applica¬ 
tion programs written in a high-level programming language. Addi¬ 
tionally# these verbs conceal from the application program the 
logical-record data-stream format that a program using the basic con¬ 
versation verbs must manage. The detailed descriptions of the mapped 
conversation verbs follow. 

Note: Every conversation is either a mapped or basic conversation. 
The mapped conversation verbs are used for operations only on mapped 
conversations. Thus# throughout the descriptions of the mapped con¬ 
versation verbs# references are made only to mapped conversations. 
The program allocates a mapped conversation when it issues the 
MC_ALLGCATE verb. Contrast this with the basic conversation verb# 
ALLOCATE# which can allocate a conversation of either type# mapped or 
basic. 
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MC_ALLOCATE 


Allocates a session between the local LU and a remote LU# and on that 
session allocates a mapped conversation between the local transaction 
program and a remote transaction program. A resource ID is assigned 
to the mapped conversation. This verb is issued prior to any verbs 
that refer to the mapped conversation. 


MC_ALLOCATE 


Supplied Parameters; 

LU.NAHE ( OWN ) 

( OTHER ( variable ) ) 

MODE_NAME ( variable ) 

TPN C variable ) 


C WHEN SESSION ALLOCATED ) 
RETURN_CONTROL ( DELAYED_ALL0CAT10N — PERMITTED ) 
C IMMEDIATE ) 


C NONE ) 

SYNC_LEVEL C CONFIRM ) 
( SYNCPT ) 


C NONE ) 

SECURITY C SAME ) 

( PGM ( USER.ID ( variable ) password ( variable ) 
PROFILE ( variable ) ) ) 

PIP C NO ) 1 

( YES ( variablel variables ... variablen ) ) 


Returned Parameters: 
RESOURCE ( variable ) 
return_code ( variable ) 


Supplied Parameters; 

LU_NAME specifies the name of the remote LU at which the remote trans¬ 
action program is located. This LU name is any name by which the 
local LU knows the remote LU for the purpose of allocating a mapped 
conversation. The local LU transforms this locally-known LU name to 
an LU name used by the network# if the names are different. 

• OWN specifies that the remote transaction program is located at 
the same LU as the local program. 

• OTHER specifies that the remote transaction program is located at 
another LU. The specified variable contains the LU name. 

MODE_NAME specifies the mode name designating the network properties 
for the session to be allocated for the mapped conversation. The net¬ 
work properties include# for example# the class of service to be used# 
and whether data i s to be enciphered or translated to ASCII before it 
is sent. The SNA-defined mode name# SNASVCMG# is not allowed to be 
specified on the MC_ALLOCATE verb (contrast this with the ALLOCATE 
verb). 

TPN specifies the name of the remote transaction program to be con¬ 
nected at the other end of the mapped conversation. TPN cannot speci¬ 
fy an SNA service transaction program name at the mapped conversation 
protocol boundary. (See "Appendix D. List of SNA Service Transaction 
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MC.ALLOCATE 


Programs" for more details about SNA service transaction program 
names.) 

RETURN_CONTROL specifies when the local LU i s to return control to the 
local program# in relation to the allocation of a session for the 
mapped conversation. An allocation error resulting from the local 
LU’s failure to obtain a session for the mapped conversation is 
reported either on this verb or a subsequent verb, depending on the 
argument specified for this parameter. An allocation error resulting 
from the remote LU’s rejection of the allocation request is reported 
on a subsequent verb. 

• UHEN_SESSION_ALLOCATED specifies to allocate a session for the 
mapped conversation before returning control to the program. An 
error in allocating a session is reported on this verb. 

• DELAYED_ALLOCATION_PERMITTED specifies to allocate a session for 
the mapped conversation after returning control to the program. 
An error in allocating a session is reported on a subsequent verb. 

• IMMEDIATE specifies to allocate a session for the mapped conver¬ 
sation if a session is immediately available, and return control 
to the program with a return code indicating whether a session is 
allocated. 

— A return code of OK indicates a session is immediately avail¬ 
able and is allocated for the mapped conversation. A session 
is immediately available when it is active, it is not allo¬ 
cated to another mapped conversation, and the local LU is the 
contention winner for the session. 

- A return code of UNSUCCESSFUL indicates a session is not imme¬ 
diately available. Allocation is not performed. 

An error in allocating a session that is immediately available is 
reported on this verb. 

SYNC_LEVEL specifies the synchronization level that the local and 
remote transaction programs can use on this mapped conversation. 

• NONE specifies that the transaction programs will not perform 
confirmation or sync point processing on this mapped conversa¬ 
tion. The programs will not issue any verbs and will not recog¬ 
nize any returned parameters relating to these synchronization 
functions. 

• CONFIRM specifies that the transaction programs can perform con¬ 
firmation processing but not sync-point processing on this mapped 
conversation. The programs may issue verbs and will recognize 
returned parameters relating to confirmation, but they will not 
issue any verbs and will not recognize any returned parameters 
relating to sync point. 

• SYNCPT specifies that the transaction programs can perform both 
confirmation and sync-point processing on this mapped conversa¬ 
tion. The programs may issue verbs and will recognize returned 
parameters relating to confirmation or sync point. For 
sync-point processing, a mapped conversation allocated with this 
synchronization level is a protected resource. 

SECURITY specifies access security information that the remote LU 
uses to verify the identity of the end user and validate access to the 
remote program and its resources. The access security information 
consists of a user ID, a password, and a profile. 

• NONE specifies to omit access security information on this allo¬ 
cation request. 

• SAME specifies to use the user ID and profile (if present) from 
the allocation request that initiated execution of the local pro¬ 
gram. The password (if present) is not used; instead, the user ID 
is indicated as being already verified. If the allocation request 
that initiated execution of the local program contained no access 
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security information# then access security information is omitted 
on this allocation request. 

• PGM specifies to use the access security information that the 
local transaction program provides on this parameter. The local 
program provides the information by means of the following argu¬ 
ments: 

— USER_ID specifies the variable containing the user ID. The 
remote LU uses this value and the password to verify the iden¬ 
tity of the end user making the allocation request. In addi¬ 
tion# the remote LU may use the user ID for auditing or 
accounting purposes# or it may use the user ID# together with 
the profile (if present)# to determine which remote programs 
the local program may access and which resources the remote 
program may access. 

— PASSWORD specifies the variable containing the password. The 
remote LU uses this value and the user ID to verify the iden¬ 
tity of the end user making the allocation request. 

— PROFILE specifies the variable containing the profile. The 
remote LU may use this value# in addition to or in place of 
the user ID# to determine which remote programs the local pro¬ 
gram may access# and which resources the remote program may 
access. 

Specifying a null value for any of the access security arguments 
is equivalent to omitting the argument. 

PIP specifies program initialization parameters for the remote trans- 
action program. 

• NO specifies that PIP data is not present. 

• YES specifies that PIP data is present. 

— vaHablel variables ••• variablen contain the PIP data to be 
sent to the remote transaction program. The PIP data consists 
of one or more subfields# each of which is specified by a sep¬ 
arate variable# variables 1 through n correspond to subfields 
1 through n. If a variable is omitted in the PIP parameter or 
it is of null value# the corresponding PIP subfield is made to 
be of zero length. The number of PIP subfields must agree 
with the number of PIP variables specified on the remote pro¬ 
gram's PROC statement (see "Transaction Program Structure and 
Execution" in Chapter 3). 

Returned Parameters: 

RESOURCE specifies the variable in which the resource ID i s to be 
returned. The length and actual format of the resource ID is product 
dependent. The resource ID is returned to the program when the return 
code is either OK or ALL0CATI0N — ERROR. 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. The RETURN^CONTROL parameter determines which of the fol¬ 
lowing return codes can be returned to the program. 

• If RETURN_CONTROL(WHEN_SESSION_ALLOCATED) is specified# one of 
the following return codes is returned: 

OK 

ALLOCATION_ERROR (with one of the following subcodes) 

— ALLOCATION_FAILURE_NO_RETRY 
— ALLOCATION_FAILURE_RETRY 
— SYNC_LEVEL_NOT_SUPPORTED_BY_LU 
— PARAMETER_ERROR (for one of the following reasons) 

— Invalid LU name 
— Invalid mode name 

• If RETURN_CONTROL(DELAYED_ALLOCATION_PERMITTED) is specified# 
one of the following return codes is returned: 
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MC_ALLOCATE 


- OK 

— PARAMETER.ERROR (for one of the following reasons) 

— Invalid LU name 
— Invalid mode name 

• If RETURN_CQNTROL(IMMEDIATE) is specified, one of the following 
return codes is returned: 

OK 

— ALLOCATION_ERROR (with the following subcode) 

— SYNC_LEVEL_NOT_SUPPORTED_BY_LU 
— PARAMETER.ERRQR (for one of the following reasons) 

— Invalid LU name 
— Invalid mode name 

- UNSUCCESSFUL (for the following reason) 

— Session not immediately available 

state.Chan ge s^ 

Send state is entered. 

ABEND Conditions: 

Parameter Check 

• The program does not have mapped conversation support defined. 

• LU.NAME(OWN) is specified and not supported. 

• MODE.NAME specifies the SNA-defined mode name, SNASVCMG. 

• TPN specifies an SNA service transaction program. 

• TPN specifies a null (zero length) value. 

• RETURN.CONTROL (DELAYED.ALLQCATIQN.PERMITTED) i s specified and 
not supported. 

• RETURN_CONTRQL(IMMEDIATE) is specified and not supported. 

• SYNC.LEVEL(SYNCPT) is specified and not supported. 

• SECURITY(SAME) is specified and not supported. 

• SECURITY(PGM(USER_ID(variable) PASSWORD(variable))) is specified 
and not supported. 

• SECURITY(PGM(PROFILE(variable))) is specified and not supported. 

• PIP(YES(variable)) is specified and not supported. 

State Check 
None 
Notes: 

1. Depending on the product, the LU may send the allocation request 
to the remote LU as soon as it allocates a session for the mapped 
conversation. Alternatively, the LU may buffer the allocation 
request until it accumulates from the PIP parameter of this verb 
or from one or more subsequent MC.SEND.DATA verbs a sufficient 
amount of information for transmission, or until the local pro¬ 
gram issues a subsequent verb other than MC.SEND.DATA that 
explicitly causes the LU to flush its send buffer. The amount of 
information that is sufficient for transmission depends on the 
characteristics of the session allocated for the mapped conversa¬ 
tion, and can vary from one session to another. 

2. The Jocal program can ensure that the remote program is connected 
as soon as possible by issuing MC.FLUSH immediately after 
MC.ALLOCATE. 

3. Two LUs connected by a session may both attempt to allocate a 
mapped conversation on the session at the same time. This is 
called contention. Contention is resolved by making one LU the 
contention winner of the session and the other LU the contention 
loser of the session. The contention-winner LU allocates a mapped 
conversation on a session without asking permission from the con¬ 
tention-loser LU. Conversely, the contention-loser LU requests 
permission from the contention-winner LU to allocate a mapped 
conversation on the session, and the contention-winner LU either 
grants or rejects the request. 
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4. If the program issues MC_ALLOCATE with the parameter 
RETURN_CONTROL(DELAYED_ALLQCATION_PERMITTED), the LU delays 
allocation of the session until it flushes its send buffer. At 
that time the LU allocates the session and transmits the allo¬ 
cation request to the remote LU. The program is unaffected by the 
delayed allocation of the session, with one exception: Mhen the 
LU allocates a contention-loser session, it does so by transmit¬ 
ting the allocation request and then waiting for information to 
arrive before returning control to the program. This can affect 
the sequence of the verbs that the program can issue. 

For example, suppose the program has the following sequence of 
verbs: 

MC_ALLOCATE with 

RETURN_CONTROL(DELAYED_ALLOCATIQN_PERMITTED) 
MCJPREPARE_TO_RECEIVE with TYPE (FLUSH) 

MC_REQUEST_TO_SEND 

In this example, assume the program is using MC_REQUEST_TO_SEND 
to prompt the remote program to begin sending information, 
instead of requesting send control. However, if the LU allocates 
a contention-loser session (and an allocation error or resource 
failure does not occur), control is not returned to the program 
after it issues the MC_PREPARE_TO_RECEIVE until the remote pro¬ 
gram sends some information. If the remote program waits for the 
REQUEST_TO_SEND notification before sending any information, a 
deadlock condition occurs. This deadlock can be avoided by issu¬ 
ing the MC_ALLOCATE with either RETURN_C0NTR0L 
(WHEN_SESSIQN_ALLOCATED) or RETURN_CQNTROL (IMMEDIATE). 

5. SYNC_LEVEL(SYNCPT) permits use of the SYNCPT and BACKOUT verbs 
and the Resynchronization transaction program (an SNA service 
transaction program), to aid in maintaining consistency across 
all protected resources within a distributed logical unit of 
work. The Resynchronization program performs sync point resyn¬ 
chronization, which maintains this consistency when session fail¬ 
ure and reinitiation occurs. See SNA Format and Protocol 
Reference Manual: Archi tec tu^e logic, for LU Type 6,2 for more 
details of sync point resynchronization. 

6. Each LU indicates at session activation time whether it will 
accept LU security parameters on allocation requests the partner 
LU sends. If the remote LU will not accept any security parame¬ 
ters from the local LU, and the local program specifies SECURI- 
TY(SAME) or SECURITY(PGM(...)), the local LU downgrades the 
specification to SECURITY(NONE). Similarly, if the remote LU 
will not accept the local LU v s verification of the user ID and 
password, and the local program specifies SECURITY(SAME), the 
local LU downgrades the specification to SECURITY(NONE)• 

7. The remote program is connected to the other end of the mapped 
conversation in receive state. 

8. The program uses the resource ID, returned to the program on the 
RESOURCE parameter, on all subsequent mapped conversation verbs 
it issues for this mapped conversation. 

9. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the allocated mapped conversa¬ 
tion. 
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MC.CONFIRM 


Sends a confirmation request to a remote transaction program and waits 
for a reply* This verb allows the local and remote programs to syn¬ 
chronize their processing with one another* The LU flushes its send 
buffer as a function of this verb. 


MC_CONFIRM 

Supplied Parameters: 

RESOURCE ( variable ) 




RETURN.CODE 1 variable ) 


REQUESTJTO_SEND_RECEIVED C variable 1 


; 


Supplied Parameters; 

RESOURCE specifies the variable containing the resource ID. The 
mapped conversation must be allocated with a synchronization level of 
CONFIRM or SYNCPT. 

Returned Parameters: 

RETURN_CQDE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. 

• OK (remote program replied MC_CGNFIRMED) 

• ALLOCATION_ERRGR 

• BACKED OUT 

• DEALL0CATE_ABEND 

• FMH_DATA_NOT_SUPPORTED 

• MAPPING_NOT_SUPPORTED 

• MAP_NQT_FOUND 

• MAP_EXECUTION_FAILURE 

• PROG_ERROR__PURGING 

• RESOURCE_FAILURE_NO_RETRY 

• RESOURCE_FAILURE_RETRY 

REQUEST w TO_SEND_RECEXVED specifies the variable in which is returned 
an indication of whether REQUEST_TO_SEND has been received. The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued MC_REQUEST_T0_SEND# requesting the local program to enter 
receive state and thereby place the remote program in send state. 

• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

State Changes (when RETURN CODE indicates OK); 

Receive state is entered when the verb is issued in defer state fol¬ 
lowing MC_PREPARE_TO_RECEIVE. 

Reset state is entered when the verb is issued in defer state follow¬ 
ing MCJDEALLOCATE. 

No state change occurs when the verb is issued in send state. 

ABEND Conditions: 

Parameter Check 

• This mapped conversation was allocated with SYNC_LEVEL(NONE). 

• RESOURCE specifies an unassigned resource ID. 
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State Check 

The mapped conversation is not in send or defer state. 

Notes: 

1. The program may use this verb for various application-level func¬ 
tions. For example: 

• The program may issue this verb immediately following an 
MC_ALLOCATE in order to determine whether the allocation of 
the mapped conversation is successful before sending any data 
records. 

• The program may issue this verb as a request for acknowledge¬ 
ment of data records it sent to the remote program. The 
remote program may respond by issuing MC_CONFIRMED as an 
indication that it received and processed the data records 
without error; or by issuing MC_SEND_ERRQR as an indication 
that it encountered an error. 

2. When REQUEST_TQ_SEND_RECEIVED indicates YES, the remote program 
requests the local program to enter receive state and thereby 
place the remote program in send state. A program enters receive 
state by means of the MC_PREPARE_TO_RECEIVE or 
MC_RECEIVE_AND_WAIT verb. The partner program enters the corre¬ 
sponding send state when it issues an MC_RECEIVE_AND_WAIT or 
MC_RECEIVE_IMMEDIATE verb and receives the SEND indication (on 
the WHAT_RECEIVED parameter). 

3. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa- 
ti on. 
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MC_CONFIRMED 


Sends a confirmation reply to the remote transaction program. This 
verb allows the local and remote programs to synchronize their proc¬ 
essing with one another. The local program can issue this verb when 
it receives a confirmation request (see the WHAT_RECEIVED parameter 
of the MC_RECEIVE_AND^WAIT or MC_RECEIVE_IMMEDIATE verb). 



Supplied Parameters: 

MC.CONFXRHED 

resource ( variable ) 


; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

State Changes: 

Receive state is entered when CONFIRM was received on the preceding 
MC_R EC ElV E_A ND_WAIT or MC_RECEIVE_IMMEDIATE. 

Send state is entered when CONFIRM_SEND was received on the preceding 
MC_RECEIVE_AND_WAIT or MC_RECEIVE_IMMEDIATE. 

Deallocate state is entered when CONFIRM_DEALLOCATE was received on 
the preceding MC_RECEIVE_AND_WAIT or MC_RECEIVE_IMMEDIATE. 

ABEND Conditions: 

Parameter Check 

RESOURCE specifies an un.assigned resource ID. 

State Check 

The mapped conversation is not in confirm state. 

Notes: 

1. The program can issue this verb only as a reply to a confirmation 
request; the verb cannot be issued at any other time. 

2. The program may use this verb for various application-level func¬ 
tions. For example, the remote program may send some data records 
followed by a confirmation request. Mhen the local program 
receives the confirmation request, it may issue this verb as an 
indication that it received and processed the data records with¬ 
out error. 

3. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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MC_DEALLOCATE 


Deallocates the specified mapped conversation from the transaction 
program. The deallocation can be either completed as part of this 
verb* or deferred until the program issues an MC_FLUSH* MC_CONFIRM* or 
SYNCPT verb. When it is completed as part of this verb it can include 
the function of the MC_FLUSH or MC_CONFIRM verb. The resource ID 
becomes unassigned when deallocation is complete. 


Supplied Parameters: 


MC.DEALLOCATE 


RESOURCE ( variable ) 


C SYNC LEVEL ) 
C FLUSH ) 

TYPE ( CONFIRM ) 

( ABEND ) 

( LOCAL ) 


Returned Parameters: 
RETURN.CODE ( variable ) 
; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID of the 

mapped conversation to be deallocated. 

TYPE specifies the type of deallocation to be performed. 

• SYNC_LEVEL specifies to perform deallocation based on the syn¬ 
chronization level allocated to this mapped conversation: 

If SYNCJ.EVEKNONE), execute the function of the MC_FLUSH 
verb and deallocate the mapped conversation normally. 

If SYNC_LEVEL(CONFIRM), execute the function of the 
MC_CONFIRM verb and if it is successful (as indicated by a 
return code of OK on this MC_DEALLOCATE verb)* deallocate the 
mapped conversation normally* if it is not successful* the 
state of the mapped conversation is determined by the return 
code. 

— If SYNC_LEVEL(SYNCPT)* defer the deallocation until the pro¬ 
gram issues a SYNCPT* or the program issues an MC_CONFIRM or 
MC_FLUSH for this mapped conversation. If the SYNCPT or 
MC_CONFIRM is successful (as indicated by a return code of OK 
on that verb) or MC_FLUSH is issued* the mapped conversation 
is then deallocated normally* otherwise* the state of the 
mapped conversation is determined by the return code. 

• FLUSH specifies to execute the function of the MC_FLUSH verb and 
deallocate the mapped conversation normally. 

• CONFIRM specifies to execute the function of the MC_CONFIRM verb 
and if it is successful (as indicated by a return code of OK on 
this MC_DEALLOCATE verb)* deallocate the mapped conversation 
normally; if it is not successful* the state of the mapped conver¬ 
sation is determined by the return code. 

• ABEND specifies to execute the function of the MC_FLUSH verb when 
the mapped conversation is in send or defer state* and deallocate 
the mapped conversation abnormally. Data purging can occur when 
the mapped conversation is in receive state. 

• LOCAL specifies to deallocate the mapped conversation locally. 
This type of deallocation must be specified if* and only if* the 
mapped conversation is in deallocate state. Deallocate state is 
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MC_DEALLOCATE 


entered when the program receives on a previously issued verb a 
return code indicating the mapped conversation has been deallo¬ 
cated (see "Return Codes” on page 4-99). 

The execution of the MC_FLUSH or MC_CONFIRM function as part of this 
verb includes the flushing of the LU’s send buffer. Mhen, instead, 
the deallocation is deferred, the LU also defers flushing its send 
buffer until the program issues a subsequent verb for this mapped con¬ 
versation . 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. The TYPE parameter determines which of the following 
return codes can be returned to the program. 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this mapped conversation is NONE, or TYPE(FLUSH), 
TYPE(ABEND), or TYPE(LOCAL) is specified, the following return 
code is returned: 

- OK (deallocation is complete) 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this mapped conversation is CONFIRM, or 
TYPE(CONFIRM) is specified, one of the following return codes is 
returned: 

— OK (deallocation is complete) 

ALLOCATION_ERROR 

DEALLOCATE_ABEND 

FMH_DATA_NOT_SUPPORTED 

- MAPPING NONSUPPORTED 

map_not!found 

- MAP_EXECUTION_FAILURE 
PROG_ERROR_PURGING 
RESOURCE_FAILURE_NO_RETRY 
RESOURCE_FAILURE_RETRY 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this mapped conversation is SYNCPT, the following 
return code is returned: 

— OK (deallocation is deferred) 

State Changes (when RETURN CODE indicates OK); 

Defer state is entered when TYPE(SYNC_LEVEL) is specified and the syn¬ 
chronization level is SYNCPT. 

Reset state is entered when TYPE(FIUSH), TYPE(CONFIRM), TYPE(LOCAL), 
or TYPE(ABEND) is specified, or when TYPE(SYNC_LEVEL) is specified 
and the synchronization level is NONE or CONFIRM. 

ABEND Conditions: 

Parameter check 

• RESOURCE specifies an unassigned resource ID. 

• TYPE(CONFIRM) is specified and the mapped conversation is allo¬ 
cated with SYNC_LEVEL(NONE). 

State check 

• TYPE(FLUSH), TYPE(CONFIRM), or TYPE(SYNC_LEVEL) is specified and 
the mapped conversation is not in send state. 

• TYPE(ABEND) is specified and the mapped conversation is not in 
send, defer, receive, confirm, or sync point state. 

• TYPE(LOCAL) is specified and the mapped conversation is not in 
deallocate state. 
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Notes: 

X* Nhen the deallocation is deferred (see the TYPE parameter), the LU 
buffers the deallocation information to be sent to the remote LU 
until the local program issues a verb that causes the LU to flush 
its send buffer. 

2. The TYPEC SYNC_LEVEL) parameter is intended to be used by the 
transaction program in order to deallocate the mapped conversa¬ 
tion based on the synchronization level allocated to the mapped 
conversation. 

• If the synchronization level is NONE, the mapped conversation 
is unconditionally deallocated. 

• If the synchronization level is CONFIRM, the mapped conversa¬ 
tion is deallocated when the remote program responds to the 
confirmation request by issuing MC_CONFIRMED. The mapped 
conversation remains allocated when the remote program 
responds to the confirmation request by issuing 
MC_SEND_ERROR. 

• If the synchronization level is SYNCPT, the mapped conversa¬ 
tion is deallocated when the local program subsequently 
issues SYNCPT and all programs throughout the transaction, 
connected to conversations having the synchronization level 
of SYNCPT, respond to the sync point request by issuing 
SYNCPT. The mapped conversation remains allocated when the 
remote program responds to the sync point request by issuing 
MC_SEND_ERROR, or one or more programs respond by issuing 
BACKOUT. 

3. The TYPE(FLUSH) parameter is intended to be used by the trans¬ 
action program in order to unconditionally deallocate the mapped 
conversation regardless of its synchronization level. 
TYPECFLUSH) is functionally equivalent to: 

• TYPECSYNCJ.EVEL) with a synchronization level of NONE. 

• TYPE(SYNC_LEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the MC_FLUSH verb. 

4. The TYPECCONFIRM) parameter is intended to be used by the trans¬ 
action program in order to conditionally deallocate the mapped 
conversation, depending on the remote program's response, when 
the synchronization level is CONFIRM or SYNCPT. TYPE(CONFIRM) is 
functionally equivalent to: 

• TYPE(SYNC_LEVEL) with a synchronization level of CONFIRM. 

• TYPECSYNC LEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the MC_CONFIRM verb. 

The mapped conversation is deallocated when the remote program 
responds to the confirmation request by issuing MC_CONFIRMED. 
The mapped conversation remains allocated when the remote program 
responds to the confirmation request by issuing MC_SEND_ERROR. 

5. The TYPEC ABEND) parameter is intended to be used by the trans¬ 
action program in order to unconditionally deallocate the mapped 
conversation regardless of its synchronization level and its cur¬ 
rent state. Specifically, the parameter is intended to be used 
when the program detects an error condition that prevents further 
useful communications, that is, communications that would lead to 
successful completion of the transaction. The specific use and 
meaning of ABEND are program-defined. 

6. The TYPEC LOCAL) parameter is intended to be used by the trans¬ 
action program in order to complete the program's deallocation of 
the mapped conversation after receiving an indication that the 
mapped conversation has been deallocated from the session, an 
indication such as a DEALLOCATEJNORMAL or RESOURCE_FAILURE_RETRY 
return code. 
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MC_DEALLOCATE 


7. The remote transaction program receives the deallocate notifica¬ 
tion by means of a return code or uhat-recelved Indication, as 
follows: 

• DEALLOCATE NORMAL return code: The local program specified 
either TYPE(FLUSH); TYPE(SYNC_LEVEL) and the synchronization 
level is NONE; or TYPE(SYNC_LEVEL), the synchronization level 
is SYNCPT, and the local program subsequently issued 
MC_FLUSH. 

• CONFIRM DEALLOCATE what-received indication: The local pro¬ 
gram specified either TYPE(CONFIRM); TYPE(SYNC_LEVEL) and the 
synchronization level is CONFIRM; or TYPE(SYNC_LEVEL)» the 
synchronization level is SYNCPT, and the local program subse¬ 
quently issued MC_CONFIRM. 

• TAKE_SYNCPT_DEALLOCATE what-received indication: The local 
program specified TYPE(SYNC_LEVEL), the synchronization level 
is SYNCPT, and the local program subsequently issued SYNCPT. 

• DEALLOCATE_ABEND return code: The local program specified 
TYPE(ABEND), with the following exception: If the remote 
program has issued MC_SEND_ERROR in receive state, a DEALLO- 
CATE_NORMAL return code is reported instead of DEALLO- 
CATE_ABEND. 

8. MC_DEALLOCATE with TYPECABEND) resets or cancels posting. If 
posting is active and the mapped conversation has been posted, 
posting is reset. If posting is active and the mapped conversa¬ 
tion has not been posted, posting is canceled (posting will not 
occur). See the MC_POST_ON_RECEIPT verb for more details about 
posting. 

9. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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MC.FLUSH 


Flushes the local LU's send buffer. The LU sends any information it 
has buffered to the remote LU. Information the LU buffers can come 
from MC_ALLOCATE, MC_DEALLOCATE, MC SEND_DATA» 
MC_PREPARE_TO_RECEIVE, or MC_SEND_ERROR. Refer to the descriptions 
of these verbs for details of the information the LU buffers and when 
buffering occurs. 


MC_FLUSH 


Supplied Parameters: 

RESOURCE ( variable ) 

; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

State Changes: 

Receive state is entered when the verb is issued in defer state fol¬ 
lowing MC_PREPARE_TO_RECEIVE. 

Reset state is entered when the verb is issued in defer state follow¬ 
ing MC_DEALLOCATE. 

No state change occurs when tbe verb is issued in send state. 

ABEND conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

State Check 

The mapped conversation is not in send or defer state. 

Notes: 

1. This verb is useful for optimization of processing between the 
local and remote programs* The LU normally buffers the data 
records from consecutive MC_SEND_DATAs until it has a sufficient 
amount for transmission. At that time it transmits the buffered 
data records. However* the local program can issue MC_FLUSH in 
order to cause the LU to transmit the buffered data records. In 
this way# the local program can minimize the delay in the remote 
program's processing of the data records. 

2. This verb can be issued after MC_J)EALLOCATE with TYPECSYNCJ.EVEL) 
when the synchronization level for the mapped conversation is 
SYNCPT. The effect to the remote program is the same as issuing 
MC_DEALLQCATE with TYPE(FLUSH). The mapped conversation is deal¬ 
located at the completion of the MC_FLUSH verb. 

3. This verb can be issued after MC_PREPARE_TO_RECEIVE with 
TYPE(SYNC_LEVEL) when the synchronization level for the mapped 
conversation is SYNCPT. The effect to the remote program is the 
same as issuing MC_PREPARE_TO_RECEIVE with TYPECFLUSH). The 
mapped conversation enters receive state at the completion of the 
MC_FLUSH verb. 

4. The LU flushes its send buffer only when it has some information 
to transmit. If the LU has no information in its send buffer* 
nothing is transmitted to the remote LU. 

5. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa- 
ti on. 
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MC_GET_ATTRIBUTES 


Returns information pertaining to the specified mapped conversation. 


MC_GET_ATTRIBUTES 


Supplied Parameters; 

RESOURCE ( variable ) 

Returned Parameters? 

[ OUN_FULLY_QUALIFIED_LU_NAHE t variable ) ] 

[ PARTNER_LU_NAME ( Variable ) ] 

[ PARTNER_FULLY_QUALIFIED_LU_NAME C variable ) ] 
[ MODE_NAME ( variable ) ] 

[ SYNC_LEVEL ( variable ) ] 

[ securxty_user_xd C variable ) ] 

[ securxty.profxle ( variable ) ] 

[ LUU.XDENTXFXER C variable ) ] 

[ CONVERSATXON.CORRELATOR ( variable ) ] 

} 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID of the 
mapped conversation of which the attributes are desired. 

Returned Parameters; 

OWN_FULLY_QUALIFIED_LU_NAME specifies the variable for returning the 
fully qualified name of the LU at which the local transaction program 
is located. If the local fully qualified LU name is not known# a null 
value is returned. 

PARTNER_LU_NAME specifies the variable for returning the name of the 
LU at which the remote transaction program is located. This is a name 
by which the local LU knows the remote LU for the purpose of allocat¬ 
ing a mapped conversation. Refer to the description of the LU_NAME 
parameter of MC_ALLOCATE for more details. 

PARTNER_FULLY_QUALIFIED_LU_NAME specifies the variable for returning 
the fully qualified name of the LU at which the remote transaction 
program is located. If the partner’s fully qualified LU name is not 
known# a null value is returned. 

MODE_NAME specifies the variable for returning the mode name for the 
session on which the mapped conversation is allocated. 

SYNC_LEVEL specifies the variable for returning the level of synchro¬ 
nization processing being used for the mapped conversation. The syn¬ 
chronization levels are: 

• NONE 

• CONFIRM 
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• SYNCPT 

SECURITY_USER_ID specifies the variable for returning the user ID 
carried on the allocation request that initiated execution of the 
local program. A null value is returned if the allocation request did 
not contain a user ID. 

SECURXTY_PROFILE specifies the variable for returning the profile 
carried on the allocation request that initiated execution of the 
local program. A null value is returned if the allocation request did 
not contain a profile. 

LUH_IDENTXFXER specifies the variable for returning the logical unit 
of work (LUW) identifier associated with the mapped conversation. The 
LUW identifier is created and maintained by the LU. The LU uses it to 
identify the most recent sync point and for accounting purposes. If 
no LUW identifier is used on the mapped conversation# a null value is 
returned. 

CONVERSATXON_CORRELATOR specifies the variable for returning the con¬ 
versation correlator. The conversation correlator is created and 
maintained by the LU. The LU uses it during sync point resynchroniza¬ 
tion. If no conversation correlator is used on the mapped conversa¬ 
tion# a null value is returned. 

State Changes: 

None 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

• SECURITY_USER_ID is specified and not supported. 

• 5ECURITY_PR0FILE is specified and not supported. 

• LUW_IDENTIFIER is specified and not supported. 

• CONVERSATION_CQRRELATOR is specified and not supported. 

State Check 
None 
Notes: 

1. The program may issue this verb in order to obtain the attributes 
of the mapped conversation# including the one by which the program 
was started. 

2. Specifying SECURITY.J)SER_ID or SECURITY_PROFILE returns the user 
ID or profile carried on the allocation request that initiated 
execution of the local program# regardless of which resource ID is 
supplied on the RESOURCE parameter. 

3. The LU creates the LUW identifier for its use during sync point 
processing# and for accounting purposes. For sync point# the LUW 
identifier uniquely identifies the most recent synchronization 
point. 

4. The LU creates the conversation correlator for its use during sync 
point resynchronization. For sync point resynchronization# the 
conversation correlator correlates the logical unit of work to 
the sync point states associated with the current instance of the 
local program. 
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MC_POST J)N JIECEIPT 

Causes the LU to post the specified mapped conversation when informa¬ 
tion is available for the program to receive. The information can be 
data# mapped conversation status# or a request for confirmation or 
sync point. WAIT should be issued after MC_P0ST_0N_RECEIPT in order 
to wait for posting to occur. Alternatively# MC_TEST may be issued 
following MC_P0ST_ON_RECEIPT in order to determine when posting has 
occurred. 



Supplied Parameters: 

MC_POST_ON_RECEIPT 

RESOURCE ( variable ) 


LENGTH ( variable ) 


• 

9 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

LENGTH specifies the variable containing a length value# which is the 

maximum length data record that the program can receive. This parame¬ 
ter is used to determine when to post the mapped conversation for the 

receipt of a data record. 

State Changes: 

None 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

♦ RESOURCE specifies an unassigned resource ID. 

State Check 

The mapped conversation is not in receive state. 

Notes: 

1. This verb is intended to be used in conjunction with MC_TEST or 

WAIT. The use of this verb and WAIT allows a program to~perform 
synchronous receiving from multiple mapped conversations# where 
the program issues this verb for each of the mapped conversations 
and then^ issues WAIT (for each mapped conversation) to wait until 
information is available to be received on the mapped conversa¬ 
tions. The use of this verb and MC_TEST allows a program to con¬ 

tinue its processing and test the mapped conversations to 
determine when information is available to be received. 

2. Posting occurs when the LU has any information that the program 
can receive# such as a data record# mapped conversation status# or 
a request for confirmation or sync point. Refer to the 
MC_RECEIVE_AND_WAIT verb for a description of the types of infor¬ 
mation a program can receive. 

3. Posting is active for a mapped conversation when 

MC_POST_ON_RECEIPT has been issued for the mapped conversation 

and posting has not yet been reset or cancelled. 

Posting is reset when any of the following verbs is issued for the 
same mapped conversation as specified on MC_POST_ON_RECEIPT after 
the mapped conversation is posted: 

BACKOUT 

MC_DEALLOCATE with TYPECABEND) 

MC_RECEIVE_AND_WAIT 

MC_RECEIVEJMMEDIATE 


4-18 


SNA Transaction Programmer's Reference Manual for LU Type 6*2 








Napped conversation verbs 


I 


MC_SEND_ERROR 

MC_TEST 

WAIT 

Posting is cancelled when any of the following verbs is issued for 
the same mapped conversation as specified on MC_POST_ON_RECEIPT 
before the mapped conversation is posted: 

BACKOUT 

MC_DEALLOCATE with TYPE(ABEND) 

NC_RECEIVE IMMEDIATE 
MC_SEND_ERROR 

In order for the program to activate posting again after posting 
has been reset or cancelled, the program issues another 
MC_POST_ON_RECEIPT. 

4. Any number of MC_POST_ON_RECEIPTs may be issued for a given mapped 
conversation before posting is reset or cancelled. The last 
MC_POST_QN_RECEIPT issued for a mapped conversation is the one 
that determines when posting will occur for data. For example, if 
a program issues MC_POST_ON_RECEIPT with LENGTHC1000) in prepara¬ 
tion to receive a 1000 byte data record, and then issues the verb 
again with LENGTHC500), posting will occur when 500 bytes of the 
data record are available. 

5. MC_POST_ON_RECEIPT with LENGTHC0) has no special significance. 
It specifies that posting for a data record is to occur upon 
receipt of any amount of the data record of one byte or more. It 
is equivalent to MC_POST_ON_RECEIPT with LENGTH(l). 

6. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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MC_PREPARE_TO_RECEIVE 

Changes the mapped conversation from send to receive state in prepara¬ 
tion to receive data. The change to receive state can be either com¬ 
pleted as part of this verb* or deferred until the program issues an 
MC_FLUSH* MC_CONFIRM* or SYNCPT verb. When it is completed as part of 
this verb it includes the function of the MC FLUSH or MC CONFIRM verb. 





MC_PREPARE_TO_RECEIVE 

RESOURCE ( variable ) 



T C SYNC LEVEL ) 

TYPE C FLUSH ) 

[ I CONFIRM ) 



T LOCKS ( SHORT ) 1 
[ ( LONG ) J 



Returned Parameters: 

RETURN.CODE ( variable 

) 


i 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

TYPE specifies the type of prepare-to-receive to be performed for this 
mapped conversation. 

• SYNCJ.EVEL specifies to perform the prepare-to-receive based on 
the synchronization level allocated to this mapped conversation: 

If SYNC_LEVEL(NONE)* execute the function of the MC_FLUSH 
verb and enter receive state. 

- If SYNC_LEVEL(CONFIRM)* execute the function of the 
MC_CONFIRM verb and if it is successful (as indicated by a 
return code of OK on this MC_PREPARE_TO_RECEIVE verb)* enter 
receive state* if it is not successful* the state of the 
mapped conversation is determined by the return code. 

— If SYNC_LEVEL(SYNCPT)* enter defer state until the program 
issues a SYNCPT* or the program issues an MC_CONFIRM or 
MC_FLUSH for this mapped conversation. If the SYNCPT or 
MC_CONFIRM is successful (as indicated by a return code of OK 
on that verb) or MC_FLUSH is issued* receive state is then 
entered for this mapped conversation* otherwise* the state of 
the mapped conversation is determined by the return code. 

• FLUSH specifies to execute the function of the MC_FLUSH verb and 
enter receive state. 

• CONFIRM specifies to execute the function of the MC_CONFIRM verb 
and* if it is successful (as indicated by a return code of OK on 
this MC_PREPARE_TO_RECEIVE verb)* enter receive state? if it is 
not successful* the state of the mapped conversation is deter¬ 
mined by the return code. 

The execution of the MC_FLUSH or MC_CONFIRM function as part of this 
verb includes the flushing of the LU f s send buffer. When* instead* 
defer state is entered* the LU defers flushing its send buffer until 
the program issues a subsequent verb for this mapped conversation. 

LOCKS specifies when control i s to be returned to the local program 
following execution of the CONFIRM function of this verb or following 
execution of an MC_CONFIRM verb issued subsequent to this verb. This 
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parameter is significant only when TYPE(CONFIRM) is also specified or 
when TYPE(SYNC_LEVEL) is also specified and the synchronization level 
for this mapped conversation is CONFIRM; or when TYPE(SYNC_LEVEl) is 
also specified* the synchronization level for this mapped conversa¬ 
tion is SYNCPT* and a subsequent MC_CONFIRM is issued. Otherwise* 
this parameter has no meaning and is ignored. 

• SHORT specifies to return control when an affirmative reply is 
received* as follows: 

- When the synchronization level is CONFIRM, return control 
from execution of this verb when an MC_CONFIRMED reply is 
received. 

— When the synchronization level is SYNCPT, return control 

immediately from execution of this verb* return control from 
execution of a subsequent MC_CONFIRM verb when a correspond¬ 
ing MC_CONFIRMED reply is received. 

• LONG specifies to return control when information* such as data* 

is received from the remote program following an affirmative 

reply* as follows: 

— When the synchronization level is CONFIRM* return control 

from execution of this verb when information is received fol¬ 
lowing an MC_CONFIRMED reply. 

— When the synchronization level is SYNCPT, return control 

immediately from execution of this verb; return control from 
execution of a subsequent MC_CONFIRM verb when information is 
received following a corresponding MC_CONFIRMED reply. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. The TYPE parameter determines which of the following 
return codes can be returned to the program. 

• If TYPE(FLUSH) is specified, or if TYPE(SYNC_LEVEL) is specified 
and the synchronization level allocated to this mapped conversa¬ 
tion is NONE, the following return code is returned: 

OK 

• If TYPE(SYNC_LEVEl) is specified and the synchronization level 
allocated to this mapped conversation is CONFIRM* or 
TYPE(CONFIRM) is specified, one of the following return codes is 
returned: 

OK 

ALL0CATI0N_ERR0R 
DEALL0CATE_ABEND 
FMH_DAT A_NOT_SUPPORTED 
MAPPING_NOT_SUPPORTED 
MAP_N0T_F0UND 
MAP_EXECUTION_FAILURE 
PR0G_ERR0R PURGING 
RESOURCE FAILURE_NO_RETRY 

- RESOURCE_FAILURE_RETRY 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this mapped conversation is SYNCPT* the following 
return code is returned: 

OK 

State Changes (when RETURN CODE indicates OKI; 

Defer state is entered when TYPE(SYNC_LEVEL) is specified and the syn¬ 
chronization level is SYNCPT. 
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MC_PREPARE_TO_RECEIVE 

Receive state is entered when TYPE(FLUSH) or TYPE(CONFIRM) is speci¬ 
fied, or when TYPE(SYNC_LEVEL) is specified and the synchronization 

level is NONE or CONFIRM. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

• TYPE(CONFIRM) is specified and the conversation is allocated with 
SYNCJ.EVELCNONE). 

• LOCKS(LONG) is specified and not supported. 

State check 

The mapped conversation is not in send state. 

Maissi 

1. The TYPE(SYNC_LEVEL) parameter is intended to be used by the 
transaction program in order to transfer send control to the 
remote program based on the synchronization level allocated to 
the mapped conversation. 

• If the synchronization level is NONE# send control is trans¬ 
ferred to the remote program without any synchronizing 
acknowledgment• 

• If the synchronization level is CONFIRM, send control is 
transferred to the remote program with confirmation 
requested. 

• If the synchronization level is SYNCPT, transfer of send con¬ 
trol is deferred. Uhen the local program subsequently issues 
SYNCPT, send control is transferred to the remote program 
with sync point requested. 

2. The TYPECFLUSH) parameter is intended to be used by the trans¬ 
action program in order to transfer send control to the remote 
program without any synchronizing acknowledgment. TYPE(FLUSH) is 
functionally equivalent to: 

• TYPE(SYNC — LEVEL) with a synchronization level of NONE. 

• TYPE(SYNC_LEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the MC_FLUSH verb. 

3. The TYPE(CONFIRM) parameter is intended to be used by the trans¬ 
action program in order to transfer send control to the remote 
program with confirmation requested. TYPE(CONFIRM) is func¬ 
tionally equivalent to: 

• TYPE(SYNC_LEVEL) with a synchronization level of CONFIRM. 

• TYPEC SYNC_LEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the MC_CONFIRM verb. 

4. The remote transaction program receives send control by means of a 
what-received indication of SEND, CONFIRM_SEND, or 
TAKE_SYNCPT_SEND, as follows: 

• SEND: The local program specified either TYPE(FLUSH); 

TYPE(SYNC_LEVEL) and the synchronization level is NONE; or 
TYPECSYNC_LEVEL), the synchronization level is SYNCPT, and 
the local program subsequently issued MC_FLUSH. 

• CONFIRM SEND: The local program specified either 

TYPE(CONFIRM); TYPECSYNC_LEVEL) and the synchronization level 
is CONFIRM; or TYPECSYNC_LEVEL), the synchronization level is 
SYNCPT, and the local program subsequently issued MC_CONFIRM. 
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• TAKE_SYNCPT_SEND: The local program specified 

TYPE(SYNC_LEVEL )* the synchronization level is SYNCPT* and 
the local program subsequently issued SYNCPT. 

5* If TYPE(SYNC_LEVEL) is specified and the synchronization level 
for the mapped conversation is SYNCPT* the LU buffers the SEND 
notification to be sent to the remote LU until the local program 
issues a verb that causes the LU to flush its send buffer, 

6* The mapped conversation for the remote program enters the corre¬ 
sponding send state when it issues an MC_RECEIVE_AND_WAIT or 
MC_RECEIVE_IMMEDIATE verb and receives the SEND indication (on 
the WHAT_RECEIVED parameter). The remote program can then send 
data to the local program, 

7, References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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MC_RECEIVE_AND_WAIT 

Waits for information to arrive on the specified mapped conversation 
and then receives the information. If information is already avail¬ 
able, the program receives it without waiting. The information can be 
a data record, mapped conversation status, or a request for confirma¬ 
tion or sync point. Control is returned to the program with an indi¬ 
cation of the type of information. 

The program can issue this verb when the mapped conversation is in 
send state. In this case, the LU flushes its send buffer, sending all 
buffered information and the SEND indication to the remote program. 
This changes the mapped conversation to receive state. The LU then 
waits for information to arrive. The remote program can send data to 
the local program after it receives the SEND indication. 


MC_RECEIVE_AND_UAIT 

Supplied Parameters: 

resource ( variable ) 


SuppI ied-and-Returned Parameters: 

LENGTH ( variable ) 


Returned Parameters: 

RETURN.CODE ( variable 1 

REQUEST_TO_SEND_RECEIVED ( variable ) 

DATA ( variable ) 

UHAT.RECEZVED ( variable ) 


[ MAP_NAHE ( variable ) ] 


• 

f 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 
Supplied-and-Returned Parameters: 

LENGTH specifies the variable containing a length value that is the 
maximum amount of the data record the program is to receive. When 
control is returned to the program this variable contains the actual 
amount of the data record the program received, up to the maximum. If 
the program receives information other than data, this variable 
remains unchanged. 

Returned Parameters; 

RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of verb exe¬ 
cution. The return codes that can be returned depend on the state of 
the mapped conversation at the time this verb is issued. 

• If this verb is issued in send state, the following return codes 
can be returned: 

OK 

ALLOCATION ERROR 
BACKED_OUT~ 

DEALLOCATE ABEND 
FMH_DATA NONSUPPORTED 
MAPPING — NONSUPPORTED 
MAP_NQT FOUND 
MAP_EXECUTION_FAILURE 
PRQG_ERROR_PURGING 
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- RESOURCE_FAILURE_NO_RETRY 
RESOURCE_FAILURE_RETRY 

• If this verb is issued in receive state, the following return 
codes can be returned: 

OK 

ALLOCATION_ERROR 

BACKED_OUT 

DEALLOCATE_ABEND 

DEALLOCATE.NORMAL 

FMH_DATA_NOT_SUPPORTED 

MAPPING_NOT_SUPPORTED 

MAP_N0T_F0UND 

- MAP_EXECUTION_FAILURE 
PR0G_ERR0R_N0_TRUNC 
PR0G_ERR0R PURGING 
RESOURCE_FAILURE_NO_RETRY 
RESOURCE_J : AILURE_RETRY 

REQUEST_TO_SEND_RECEIVED specifies the variable in which is returned 
an indication of whether REQUEST^TQ_SEND has been received* The indi¬ 
cation is either YES or NO* 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program* The remote program has 
issued MC_REQUEST_TO_SEND* requesting the local program to enter 
receive state and thereby place the remote program in send state 

• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

DATA specifies the variable in which the program is to receive the 
data* When the program receives information other than data* as indi¬ 
cated by the WHAT_RECEIVED parameter* nothing is placed in this vari¬ 
able. 

WHAT_RECEXVED specifies the variable in which is returned an indi¬ 
cation of what the transaction program receives. The program should 
examine this variable only when RETURN_CODE indicates OK* otherwise* 
nothing is placed in this variable* 

• DATA_COMPLETE indicates the program received a complete data 
record or the last remaining portion of the record. 

• DATA_TRUNCATED indicates the program received less than a com¬ 
plete data record* and the LU discarded the remainder of the data 
record, 

• DATA_INCOMPLETE indicates the program received less than a com¬ 
plete data record* and the LU retained the remainder of the data 
record* The program may receive the remainder of the data record 
by issuing another MC RECEIVE AND_UAIT (or possibly multiple 
MC_RECEIVE_ANDJ*JAITs) . 

• FMH_DATA_COMPLETE indicates the program received a complete data 
record or the last remaining portion of the record* and the data 
record contains FM headers* 

• FMH_DATA_TRUNCATED indicates the program received less than a 
complete data record containing FM headers* and the LU discarded 
the remainder of the data record. 

• FMH_DATA_INCOMPLETE indicates the program received less than a 
complete data record containing FM headers* and the LU retained 
the remainder of the data record. The program may receive the 
remainder of the data record by issuing another 
MC_RECEIVE_ANDJ4AIT (or possibly multiple MCJ*ECEIVE_AND_WAITs>. 

• SEND indicates the remote program has entered receive state* 
placing the local program in send state* The local program may 
now issue MC_SEND_DATA. 


Chapter 4* Conversation Verbs 


4-25 



MC_RECEIVE_AND_WAXT 


I 


I 


• CONFIRM indicates the remote program has issued MC_CONFIRM# 
requesting the local program to respond by issuing MC_CONFIRMED. 
The program may respond# instead# by issuing a verb other than 
MC — CONFIRMED# such as MC_SEND_ERROR* 

• CONFIRM SEND indicates the remote program has issued 
MC_PREPARE_TOJ*ECEIVE with TYPECCONFIRM); or with 
TYPE(SYNC_LEVEL)# and either the synchronization level is CON¬ 
FIRM# or it is SYNCPT and the remote program subsequently_issued 
MC_CONFIRM. The local program may respond by issuing 
MC_CONFIRMED# or by issuing another verb such as MC_SEND_ERROR* 

• CONFIRM — DEALLOCATE indicates the remote program has issued 

MCJDEALLOCATE with TYPECCONFIRM)? or with TYPECSYNCJ.EVEL)# and 
either the synchronization level is CONFIRM# or it is SYNCPT and 
the remote program subsequently issued MC_CONFIRM. The local 
program may respond by issuing MC_CONFIRMED# or by issuing anoth¬ 
er verb such as MC_SEND_ERROR. 

• TAKE_SYNCPT indicates the remote program has issued SYNCPT# 

requesting the local program to respond by issuing SYNCPT in order 
to perform the sync-point function on all protected resources 
throughout the transaction* Issuing the SYNCPT verb also causes 
an affirmative reply to be returned to the remote program if the 
sync-point function is successful* The program may respond# 
instead# by issuing a verb other than SYNCPT# such as BACKOUT or 
MC_SEND_ERROR. 

• TAKE_SYNCPT_SEND indicates the remote program has issued 

MC_PREPARE_TO_RECEIVE with TYPE(SYNC_LEVEL)# the synchronization 
level is SYNCPT# and the remote program subsequently issued 

SYNCPT* The local program may respond by issuing SYNCPT# or by 
issuing another verb such as BACKOUT or MC_SEND_ERROR. 

• TAKE_SYNCPT_DEALLOCATE indicates the remote program has issued 
MCJ)EALLOCATE with TYPE(SYNC_LEVEL)# the synchronization level is 
SYNCPT# and the remote program subsequently issued SYNCPT. The 
local program may respond by issuing SYNCPT# or by issuing another 
verb such as BACKOUT or MC_SEND_ERROR. 

MAP_NAME specifies the variable in which is returned the name of the 
format (such as the name of a DSECT or DECLARE) that defines the 
structure of the data record. A null value returned means the data 
record has not been mapped. That is# mapping of this data record is 
suppressed* 

When the program receives information other than data# as indicated by 
the WHAT_RECEIVED parameter# nothing is placed in this variable* 

State Changes (when RETURN CODE indicates OK): 

Receive state is entered when the verb is issued in send state and 
WHAT_RECEIVED indicates DATA_COMPLETE# DATA_INC0MPLETE# 

FMH_DATA_COMPLETE, or FMH_DATA_INCOMPLETE. 

Send state is entered when WHAT_RECEIVED indicates SEND. 

Confirm state is entered when WHAT_RECEIVED indicates CONFIRM, CON- 
FIRM_$END# or CONFIRM_DEALLOCATE* 

Sync-point state is entered when WHAT_RECEIVED indicates TAKE_SYNCPT# 
TAKE_SYNCPT_SEND# or TAKE_SYNCPT_DEALLOCATE. 

No state change occurs when the verb is issued in receive state and 

WHAT^RECEIVED indicates DATA_COMPLETE# DATA — INCOMPLETE# 

FMH_DATA_COMP.LETE, or FMH_DATA_INCOMPLETE. 

ABEND Conditions: 

Parameter Check 

• RESOURCE specifies an unassigned resource ID* 

• MAP_NAME is specified and not supported. 
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State Check 

The mapped conversation is not in send or receive state. 

Notes: 

1. When the program issues MC_RECEIVE_AND_WAIT in send state* the LU 

implicitly executes an MC_PREPARE_TO_RECEIVE with TYPE(FLUSH) 
before executing the MC_RECEIVE_AND_WAIT. Refer to the 

description of MC_PREPARE_TO_RECEIVE for details of its function. 

2. The mapped conversation protocol boundary provides for the send¬ 
ing and receiving of data records. Unlike the logical records 
defined for the basic conversation protocol boundary* data 
records contain only data; they do not contain the logical record 
length field. 

3. The MC_RECEIVE_AND < _WAIT verb can receive only as much of the data 
record as specified by the LENGTH parameter. The WHAT_RECEIVED 
parameter indicates whether the program has received a complete 
or incomplete data record* as follows: 

• The WHAT_RECEIVED parameter indicates DATA_COMPLETE or 
FMH_DATA_COMPLETE when the program receives a complete data 
record or the last remaining portion of a data record. The 
length of the record or portion of the record is equal to or 
less than the length specified on the LENGTH parameter. 

• The WHAT_RECEIVED parameter indicates DATA TRUNCATED* 
DATA_INCOMPLETE* FMH_DATA_TRUNCATED, or FMH_DATA_INCOMPLETE 
when the program receives a portion of a data record other 
than the last remaining portion. The data record is incom¬ 
plete because the length of the record is greater than the 
length specified on the LENGTH parameter* the amount received 
equals the length specified. 

4. Whether the LU discards or retains the remainder of an incomplete¬ 
ly received data record depends on the product and the data-record 
format indicated by the format name returned on the MAP_NAME 
parameter. A product may imply by some or all of its format names 
(including the null value) that the remaining data is discarded* 
rather than retained. 

5. MC_RECEIVE_AND_WAIT with LENGTHC0) has no special significance. 
The type of information available is indicated by the RETURN^CODE 
and WHAT_RECEIVED parameters* as usual. However* the program 
receives no data. 

6. The program receives only one kind of information at a time. For 
example* it may receive data or a CONFIRM request* but it does not 
receive both at the same time. The RETURN_CODE and WHAT_RECEIVED 
parameters indicate to the program the kind of information the 
program receives. 

7. MC_RECEIVE_AND_WAIT includes posting. If posting is already 
active when this verb is issued* this verb supersedes the prior 
MC_P0ST_0N_RECEIPT function. Posting is reset at the completion 
of this verb. See the MC_POST_ON_RECEIPT verb for more details 
about posting. 

8. It is the responsibility of both sending and receiving installa¬ 
tions to maintain the map-name definitions referenced by their 
application transaction programs. 

9. The function of FM headers in the data record is significant only 
to the transaction programs* the sending and receiving LUs pel— 
form no FM-header related processing other than indicating that 
the data record contains FM headers. The presence of FM headers 
in the data record is specified by the remote transaction program 
by means of the FMH_DATA parameter of the MC_SEND_DATA that sent 
the data record. 

10. The REQUEST_TO_SEND notification is usually received when the 
local transaction program is in send state* and reported to the 
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program on an MC_SEHD_DATA verb or on an MC_SEND_ERROR verb issued 
in send state. However* the notification can be received when the 
program is in receive state under the following conditions: 

• When the local program just entered receive state and the 
remote program issued MC_REQUEST_TO_SEND before it entered 
send state. 

• When the remote program has just entered receive state by 
means of the MC PREPARE_TO_RECEIVE verb (not 
MC_RECEIVE_AND_WAIT)* and then issued MC_REQUEST_TO_SEND 
before the local program enters send state. This can occur 
because the REQUEST_TO_SEND is transmitted as an expedited 
request and can therefore arrive ahead of the request carry¬ 
ing the SEND indication. Potentially* the local program can¬ 
not distinguish this case from the first. This ambiguity is 
avoided when the remote program waits until it receives 
information from the local program before it issues the 
MC_REQUEST_TO_SEND. 

• When the remote program issues the MC_REQUEST_TO_SEND in send 
state (see "Notes on Implementation Details" in Appendix A). 

11. The REQUEST_TO_SEND notification is returned to the program in 
addition to (not in place of) the information indicated by the 
RETURN.CODE and WHAT_RECEIVED parameters. 

12. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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MC_RECEXVE_IMMEDXATE 

Receives any information that is available from the specified mapped 
conversation^ but does not wait for information to arrive. The infoi— 
mation (if any) can be data* mapped conversation status/ or a request 
for confirmation or sync point. Control is returned to the program 
with an indication of whether any information was received and/ if soz 
the type of information. 


MC_RECEIVE_IMMEDIATE 

Supplied Parameters: 

resource ( variable ) 


SuppI i ed-and-Returned Parameters: 

LENGTH ( variable ) 


Returned Parameters: 

RETURN.CODE ( variable ) 

REQUEST_TO_SEND_RECEXVED ( Variable ) 

DATA ( variable ) 

UHAT.RECEXVED ( variable ) 


[ MAP.NAME ( variable ) ] 


5 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

Supplied-and-Returned Parameters: 

LENGTH specifies the variable containing a length value that is the 
maximum amount of the data record the program is to receive. Uhen 
control is returned to the program this variable contains the actual 
amount of the data record the program received/ up to the maximum. If 
the program receives information other than data/ or no information at 
all/ this variable remains unchanged. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the”program. The return code indicates the result of verb exe¬ 
cution. 

• OK 

• ALL0CATI0N_ERR0R 

• BACKED_OUT 

• DEALLOCATE_ABEND 

• DEALLOCATE_NORMAL 

• FMH_DATA_NOT_SUPPORTED 

• MAPPING_NOT_SUPPORTED 

• MAP_N0T_F0UND 

• MAP_EXECUTION FAILURE 

• PR0G_ERR0R_N0_TRUNC 

• PROG_ERROR_PURGING 

• RESOURCE_FAILURE_NO_RETRY 

• RESOURCE_FAILURE_RETRY 

• UNSUCCESSFUL - There is nothing to receive. 

REQUEST_TO_SEND_RECEXVED specifies the variable in which is returned 
an indication of whether REQUEST_TO_SEND has been received. The indi¬ 
cation is either YES or NO. 
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• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued MC_REQUEST_TQ_SEND, requesting the local program to enter 
receive state and thereby place the remote program in send state 

• HO indicates a REQUEST_TO_SEND notification has not been 
received, 

DATA specifies the variable in which the program is to receive the 
data. Uhen the program receives information other than data, as indi¬ 
cated by the WHAT_RECEIVED parameter, nothing is placed in this vari¬ 
able. 

I4HAT_RECEIVED specifies the variable in which is returned an indi¬ 
cation of what the transaction program received. The program should 
examine this variable only when RETURN_CODE indicates OK; otherwise, 
nothing is placed in this variable. 

• DATA_COMPLETE indicates the program received a complete data 
record or the last remaining portion of the record. 

• DATA_TRUNCATED indicates the program received less than a com¬ 
plete data record, and the LU discarded the remainder of the data 
record. 

• DATA_INCOMPLETE indicates the program received less than a com¬ 
plete data record, and the LU retained the remainder of the data 
record. The program may receive the remainder of the data record 
by issuing another MC_RECEIVE_IMMEDIATE (or possibly multiple 
MC_RECEIVE_IMMEDIATEs). 

• FMH_DATA_COMPLETE indicates the program received a complete data 
record or the last remaining portion of the record, and the data 
record contains FM headers. 

• FMH_JDATA_TRUNCATED indicates the program received less than a 
complete data record containing FM headers, and the LU discarded 
the remainder of the data record. 

• FMH_DATA_INCOMPLETE indicates the program received less than a 

complete data record containing FM headers, and the LU retained 
the remainder of the data record. The program may receive the 
remainder of the data record by issuing another 

MC_RECEIVE_IMMEDIATE (or possibly multiple 

MC_RECEIVE_IMMEDIATEs). 

• SEND indicates the remote program has entered receive state, 
placing the local program in send state. The local program may 
now issue MC_SEND_DATA. 

• CONFIRM indicates the remote program has issued MC_CONFIRM, 
requesting the local program to respond by issuing MC_CONFIRMED. 
The program may respond, instead, by issuing a verb other than 
MC_CONFIRMED, such as MC_SEND_ERROR. 

• CONFIRM..SEND indicates the remote program has issued 

MC_PREPARE_TO_RECEIVE wi th TYPE(CONFIRM); or wi th 
TYPE(SYNC_LEVEL), and either the synchronization level is CON¬ 
FIRM, or it is SYNCPT and the remote program subsequently issued 
MC_CONFIRM. The local program may respond by issuing 
MC_CONFIRMED, or by issuing another verb such as MC_SEND_ERROR. 

• CONFIRM_DEALLOCATE indicates the remote program has issued 
MC_DEALLOCATE with TYPE(CQNFIRM); or with TYPE(SYNC_LEVEL), and 
either the synchronization level is CONFIRM, or it is SYNCPT and 
the remote program subsequently issued MC_CONFIRM. The local 
program may respond by issuing MC_CONFIRMED, or by issuing anoth¬ 
er verb such as MC_SEND_ERROR. 

• TAKE_SYNCPT indicates the remote program has issued SYNCPT, 
requesting the local program to respond by issuing SYNCPT in order 
to perform the sync-point function on all protected resources 
throughout the transaction. Issuing the SYNCPT verb also causes 
an affirmative reply to be returned to the remote program if the 
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sync-point function is successful* The program may respond# 
instead# by issuing a verb other than SYNCPT# such as BACKOUT or 
MCJ>END_ERROR. 

• TAKE_SYNCPT_SEND indicates the remote program has issued 
MC_PREPARE_TO_RECEIVE with TYPE(SYNC_LEVEL)# the synchronization 
level is SYNCPT# and the remote program subsequently issued 
SYNCPT. The local program may respond by issuing SYNCPT# or by 
issuing another verb such as BACKOUT or MC_SEND_ERROR. 

• TAKE_SYNCPT_DEALLOCATE indicates the remote program has issued 
MC_DEALLOCATE with TYPE(SYNC_LEVEL), the synchronization level is 
SYNCPT# and the remote program subsequently issued SYNCPT. The 
local program may respond by issuing SYNCPT# or by issuing another 
verb such as BACKOUT or MC_SENDJERROR. 

HAP_NAME specifies the variable in which is returned the name of the 
format (such as the name of a DSECT or DECLARE) that defines the 
structure of the data record. A null value returned means the data 
record has not been mapped. That is# mapping of this data record is 
suppressed. 

hlhen the program receives information other than data# as indicated by 
the WHAT_RECEIVED parameter# nothing is placed in this variable. 

State Changes (when RETURN CODE indicates OK); 

Send state is entered when WHAT_RECEIVED indicates SEND. 

Confirm state is entered when WHAT_RECEIVED indicates CONFIRM# CON- 
FIRM_SEND# or CONFIRM_DEALLOCATE. 

Sync-point state is entered when WHAT_RECEIVED indicates TAKE_SYNCPT, 
TAKE_SYNCPT_SEND# or TAKE_SYNCPT_DEALLOCATE. 

No state change occurs when WHAT RECEIVED indicates DATA w COMPLETE# 
DATA_INCQMPLETE# FMH_DATA_COMPLETE# or FMH_DATA_INCOMPLETE. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

• MAP_NAME is specified and not supported. 

State Check 

The mapped conversation is not in receive state. 

Notes: 

1. The mapped conversation protocol boundary provides for the send¬ 
ing and receiving of data records. Unlike the logical records 
defined for the basic conversation protocol boundary# data 
records contain only data# they do not contain the logical record 
length field. 

2. The MC_RECEIVE_IMMEDIATE verb can receive only as much of the data 
record as specified by the LENGTH parameter. The UHAT.RECEIVED 
parameter indicates whether the program has received a complete 
or incomplete data record# as follows: 

• The WHAT.RECEIVED parameter indicates DATA_COMPLETE or 
FMH_DATA__COMPLETE when the program receives a complete data 
record or the last remaining portion of a data record. The 
length of the record or portion of the record is equal to or 
less than the length specified on the LENGTH parameter. 

• The WHAT_RECEIVED parameter indicates DATA_TRUNCATED# 
DATA.INCOMPLETE# FMH_DATA_TRUNCATED# or FMH_DATA_INCOMPLETE 
when the program receives a portion of a data record other 
than the last remaining portion. The data record is incom¬ 
plete because: 
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— The length of the record is greater than the length speci¬ 
fied on the LENGTH parameter; in this case the amount 
received equals the length specified* 

— Only a portion of the data record is available* the por¬ 
tion being equal to or less than the length specified on 
the LENGTH parameter* 

3* Whether the LU discards or retains the remainder of an incomplete¬ 
ly received data record depends on the product and the data-record 
format indicated by the format name returned on the MAP_NAME 
parameter. A product may imply by some or all of its format names 
(including the null value) that the remaining data is discarded* 
rather than retained. 

4. MC_RECEIVE_IMMEDIATE with LENGTH(O) has no special significance. 
The type of information available* if any* is indicated by the 
RETURN_CODE and WHAT_RECEIVED parameters* as usual. However* the 
program receives no data. 

5. The program receives only one kind of information at a time. For 
example* it may receive data or a CONFIRM request* but it does not 
receive both at the same time. The RETURN_CODE and WHAT_RECEIVED 
parameters indicate to the program the kind of information the 
program receives* if any. 

6. MC_RECEIVE_IMMEDIATE resets or cancels posting. If posting is 
active and the mapped conversation has been posted* posting is 
reset. If posting is active and the mapped conversation has not 
been posted* posting is cancelled (posting will not occur). See 
the MC_POST_ON_RECEIPT verb for more details about posting. 

7. It is the responsibility of both sending and receiving installa¬ 
tions to maintain the map-name definitions referenced by their 
application transaction programs. 

8. The function of FM headers in the data record is significant only 
to the transaction programs* the sending and receiving LUs per¬ 
form no FM-header related processing other than indicating that 
the data record contains FM headers. The presence of FM headers 
in the data record is specified by the remote transaction program 
by means of the FMH_DATA parameter of the MC_$END_DATA that sent 
the data record. 

9. The REQUEST_TO_SEND notification is usually received when the 
local transaction program is in send state, and reported to the 
program on an MC_SEND_DATA verb or on an MC_SEND_ERROR verb issued 
in send state. However* the notification can be received when the 
program is in receive state under the following conditions: 

• When the local program just entered receive state and the 
remote program issued MC_REQUEST_TO_$END before it entered 
send state. 

• When the remote program has just entered receive state by 
means of the MC_PREPARE_TO_RECEIVE verb (not 
MC_RECEIVE_AND_WAIT)* and then issued MC_REQUEST_TO_SEND 
before the local program enters send state. This can occur 
because the MC_REQUEST_TO_SEND is transmitted as an expedited 
request and can therefore arrive ahead of the request carry¬ 
ing the SEND indication. Potentially* the local program can¬ 
not distinguish this case from the first. This ambiguity is 
avoided when the remote program waits until it receives 
information from the local program before it issues the 
MC_REQUEST_TO_SEND. 

• When the remote program issues the MC_REQUEST_T0_SEND in send 
state (see "Notes on Implementation Details" in Appendix A). 

10. The REQUEST_TO_SEND notification is returned to the program in 
addition to (not in place of) the information indicated by the 
RETURN_CODE and WHAT_RECEIVED parameters. 
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11. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa- 
ti on. 
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Notifies the remote program that the local program is requesting^to 
enter send state for the mapped conversation. The mapped conversation 
Mill be changed to send state Mhen the local program subsequently 
receives a SEND indication from the remote program. 


MCJ*EQUEST_TO_SEND 

Supplied Parameters: 

resource ( variable ) 


; 


Supplied Parameters; 

RESOURCE specifies the variable containing the resource ID. 

State Changes: 

None 

ABEND Conditions: 

Parameter Check 

RESOURCE specifies an unassigned resource ID. 

State Check 

• The mapped conversation is not in receive# confirm# or sync-point 
state. 

Notes: 

1. The REQUEST_TO_SEND notification is indicated to the remote pro¬ 
gram by means of the REQUEST_TO_SEND_RECEIVED parameter. When 
the REQUEST_TO_SEND_RECEIVED parameter is set to YES# the remote 
program is requested to enter receive state and thereby place the 
local program in send state. A program enters receive state by 
means of the MC_RECEIVE_AND_WAIT or MC_PREPARE_TO_RECEIVE verb. 
The partner program enters the corresponding send state Mhen it 
issues an MC_RECEIVE_AND_WAIT or MC_RECEIVE_IMMEDIATE verb and 
receives the SEND indication (on the WHAT_RECEIVED parameter). 

2. The REQUEST_TO_SEND_RECEIVED indication of YES is normally 
returned to the remote program Mhen it is in send state# that is# 
on an MC_SEND_DATA or on an MC_$END_ERROR issued in send state. 
Honever# it can be returned on an MC_RECEIVE_AND_WAIT or 
MC_RECEIVE_IMMEDIATE verb# see the description of 
MC_RECEIVE_AND_WAIT or MC_RECEIVE — IMMEDIATE for details about 
Mhen this can occur. 

3. When the remote LU receives the REQUEST_TO_SEND notification# it 
retains the notification until the remote program issues a verb on 
Mhich the notification can be indicated# that is# a verbMith the 
REQUEST_TO_SEND_RECEIVED parameter. The remote LU Mill retain 
only one REQUEST_TO_SEND notification at a time (per mapped con¬ 
versation); additional notifications are discarded until the 
retained notification is indicated to the remote program. It is 
therefore possible for the local program to issue the 
MC_REQUEST_TO_SEND verb more times than are indicated to the 
remote program. 

4. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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MC_SEND_DATA 


Sends one data record to the remote transaction program* The data 
record consists entirely of data. The program can specify data map¬ 
ping as a function of this verb# and it can indicate whether the data 
record includes FM headers. 


HC_SEND_DATA 


Supplied Parameters: 
RESOURCE ( variable ) 
DATA ( variable ) 
LENGTH ( variable ) 


[ MAP_NAME ( NO ) 

( YES ( variable ) ) 

[ FMHJJATA C MQ 1 1 

( YES ) J 

Returned Parameters; 

RETURN.CODE ( variable ) 
REQUEST_TO_SEND_RECEXVED ( variable ) 
; 


Supplied Parameter s: 

RESOURCE specifies the variable containing the resource ID of the 
mapped conversation on which the data record i s to be sent. 

DATA specifies the variable containing the data record to be sent. 
The data record consists entirely of data. 1 The length of the data 
record is given by the LENGTH parameter. 

LENGTH specifies the variable containing the length of the data record 
to be sent. The length may be zero or greater. If zero# a null data 
record is sent. 

NAP_NAME specifies whether the data record i s to be mapped: 

• NO specifies that data mapping i s to be suppressed. The data 
record is sent as is# without being mapped. 

• YES specifies that the data record is to be mapped using the map 
name contained in the variable. The map name is a non-null 
user-defined name that identifies the format of the data record 
and the mapping to be performed on the data record before it is 
sent. 

FMH_DATA specifies whether the data record contains FM headers. 

• NO specifies that FM headers are not present in the data record. 

• YES specifies that the data record contains FM headers. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. 


The data format for the basic conversation verb# SEND_DATA# con¬ 
sists of logical records# which include a length field. See the 
description of SEND_DATA for more details. 
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• OK 

• ALLOCATION_ERROR 

• BACKED_OUT 

• DEALLOCATE_ABEND 

• FMH_DATA_NOT_SUPPORTED 

• MAPPING_NOT_SUPPQRTED 

• MAP_NOT_FOUND 

• MAP_EXECUTION_FAILURE 

• PROG_ERROR_PURGING 

• RESOURCE_FAILURE NQ_RETRY 

• RESOURCE.FAILURElRETRY 

REQUEST_TO_SEHD_RECEIVED specifies the variable in which is returned 

an indication of whether REQUEST_TO_SEND has been received* The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued MC_REQUEST_TO_SEND, requesting the local program to enter 
receive state and thereby place the remote program in send state. 

• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

State Changes tnhen RETURN CODE indicates OKI; 

None 

ABEND Conditions; 

Parameter Check 

• RESOURCE specifies an unassigned resource ID. 

• MAP_NAME(YES(variable)) is specified and not supported. 

• FMH_DATA(YES) is specified and not supported. 

State Check 

The mapped conversation is not is send state. 

Notes: 

1. The mapped conversation protocol boundary provides for the send¬ 
ing and receiving of data records. Unlike the logical records 
defined for the basic conversation protocol boundary, data 
records contain only data; they do not contain the logical record 
length field. 

2. The MC_SEND_DATA verb sends one complete data record. Thus, the 
sending program cannot truncate a data record. 

3. The LU buffers the data to be sent to the remote LU until it accu¬ 
mulates from one or more MC_SEND_DATA verbs a sufficient amount 
for transmission, or until the local program issues a verb that 
causes the LU to flush its send buffer. The amount of data that 
is sufficient for transmission depends on the characteristics of 
the session allocated for the mapped conversation, and can vary 
from one session to another. 

4. The MAP_NAME parameter is used to specify data mapping. The data 
mapping function uses the MAP_NAME parameter as follows: 

♦ MAP_NAME(NQ) is used to generate a null (zero-length) value 
for the map name, which suppresses data mapping. 

• MAP_NAME(YES(variable)) is used to specify a non-null map 
name, which invokes data mapping. 

The data mapping may be performed by the local LU, remote LU, or 
both, depending on the data mapping function. Mhen a mapped con¬ 
versation is started, data mapping is initially suppressed until 
MAP_NAME(YES(variable)) is specified, at which time data mapping 
is invoked. During the remainder of the conversation data mapping 
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of each data record is either invoked or suppressed as the 
MAP_NAME parameter specifies. 

The data mapping function underlying the mapped conversation pro¬ 
tocol boundary includes the sending of the map name to the remote 
LU. The local LU sends the map name when data mapping is first 
invoked on the mapped conversation# and thereafter whenever the 
one to be sent differs from the one previously sent. This proto¬ 
col for. sending the map name and data applies Independently in 
each direction on the mapped conversation. 

5. The data mapping function underlying the mapped conversation pro¬ 
tocol boundary may include mapping of the map name itself# depend¬ 
ing on the mapping function. Consequently# the local program may 
specify a map name that differs from the map name the remote pro¬ 
gram receives. For example# the DATA parameter may specify a 
high-level-language data structure# which the local LU must seri¬ 
alize for transmission. Correspondingly# the remote LU may have 
to map the serialized data into a (possibly different) 
high-level-language data structure for the remote program. In 
this example# the local LU maps the program-speci f i ed map name to 
a second map name that describes the format of the serialized 
data# and sends the second map name together with the serialized 
data to the remote LU. The remote LU maps the second map name to a 
third map name that describes the structure of the data passed to 
the remote program. 

6. It is the responsibility of both sending and receiving installa¬ 
tions to maintain the map-name definitions referred to by their 
application transaction programs. 

7. The function of FM headers in the data record is significant only 
to the transaction programs# the sending and receiving LUs per¬ 
form no FM-header related processing other than indicating that 
the data record contains FM headers. The presence of FM headers 
in the data record is indicated to the remote transaction program 
by means of the WHAT_RECEIVED parameter of the 
MC_RECEIVE_ANDJdAIT or MC_RECEIVE_IMMEDIATE verb that receives 
the data record. 

8. When REQUEST_TO_SEND_RECEIVED indicates YES# the remote program 
is requesting the local program to enter receive state and thereby 
place the remote program in send state. A program enters receive 
state by means of the MC_PREPARE_TQ_RECEIVE or 
MC_RECEIVE_AND_WAIT verb. The partner program enters the corre¬ 
sponding send state when it issues an MC_RECEIVE_AND_WAIT or 
MC_RECEIVE IMMEDIATE verb and receives the SEND indication (on 

» the WHAT_RECEIVED parameter). 

9. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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HC_SEND_ERROR 


Informs the remote transaction program that the local program 
detected an application error. If the mapped conversation is in send 
state* the LU flushes its send buffer. 

Upon successful completion of this verb* the local program is in send 
state and the remote program is in receive state. Further action is 
defined by transaction program-logic. 



Supplied Parameters: 

MC_SEND_ERROR 

resource ( variable ) 


Returned Parameters: 

RETURN.CODE ( variable ) 

REQUEST_TO_SEND_RECEXVED ( variable ) 


; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. The return codes that can be returned depend on the state 
of the mapped conversation at the time this verb is issued: 

• If this verb is issued in send state* the following return codes 
can be returned: 

- OK 

ALLOCATION_ERROR 

- BACKED_OUT 

- DEALLOCATE_ABEND 

- PROG_ERROR_PURGING 
RESOURCE_FAILURE_NO_RETRY 
RES0URCE_FA1LURE_RETRY 
FMH_DATA NOT SUPPORTED 

- MAPPING_NOT_SUPPORTED 

- MAP_NOT_FOUND 

- MAP_EXECUTION_FAILURE 

• If this verb is issued in receive state* the following return 
codes can be returned: 

OK 

DEALLOCATE NORMAL 
RESOURCE FAILURE_NO_RETRY 
RESOURCE_FAILURE_RETRY 

• If this verb is issued in confirm state or sync-point state* the 
following return codes can be returned: 

- OK 

- RESOURCE FAILURE_NO_RETRY 

- RESOURCE_FAILURE_RETRY 

REQUEST_TO_SEND_RECEIVED specifies the variable in which is returned 
an indication of whether REQUEST_TO_SEND has been received. The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued MC_REQUEST_TO_SEND, requesting the local program to enter 
receive state and thereby place the remote program in send state. 
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• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

State Changes (when RETURN CODE indicates OK): 

Send state is entered when the verb is issued in receive* confirm* or 

sync-point state. 

No state change occurs when the verb is issued in send state. 

ABEND Conditions: 

Parameter Check 

RESOURCE specifies an unassigned resource ID. 

State Check 

The mapped conversation is not in send* receive* confirm* or 
sync-point state. 

Notes: 

1. The LU may send the error notification to the remote LU immediate¬ 
ly* that is* during the processing of this verb* or the LU may 
defer sending the notification until a later time. The determi¬ 
nation is made as follows: 

• If the local product does not support the MC_FLUSH verb (see 
"Notes on Implementation Details” in Appendix A)* then the LU 
sends the error notification immediately. 

• If the local product does support the MC_FLU$H verb* then the 
LU may or may not send the notification immediately* depend¬ 
ing on the product. If the LU defers sending the notifica¬ 
tion* it buffers the notification until it accumulates a 
sufficient amount of information for transmission* or until 
the local program issues a verb that causes the LU to flush 
its send buffer. The amount of information that is sufficient 
for transmission depends on the characteristics of the ses¬ 
sion allocated for the mapped conversation* and can vary from 
one session to another. 

2. The local program can ensure that the remote program receives the 
error notification as soon as possible by issuing MC_FLUSH imme¬ 
diately after MC_SEND_ERROR. 

3. MC_SEND_ERROR is reported to the remote transaction program as 
one of the following return codes: 

• PROG_ERRQR_NOJTRUNC - The local program issued MC_SEND_ERROR 
in send state. No da*a truncation occurs at the mapped con¬ 
versation protocol boundary. 

• PROG_ERROR_PURGING - The local program issued MC_SEND_ERROR 
in receive state and all data sent by the remote program and 
not yet received by the local program* if any* has been 
purged; or the local program issued MC_SEND_ERROR in confirm 
or sync-point state* in which case no purging has occurred. 

4. When MC_SEND_ERROR is issued in receive state* purging of incom¬ 
ing information occurs. The incoming information that is purged 
includes the following return code indications: 

• ALLOCATION ERROR 

• BACKED^OUT 

• DEALLOCATE ABEND 

• FMHJ)ATA NONSUPPORTED 

• MAPPING_NOT SUPPORTED 

• MAP_N0T_F0UND 

• MAP_EXECUTION — FAILURE 

• PR0G_ERR0R NOJTRUNC 

• PROG_ERROR_PURGING 
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The return code DEALLOCATE_NORMAL is reported instead of ALLO- 
CATI0N_ERR0R or DEALLOCATE_ABEND, The return code OK is reported 
instead of the other return codes* When the return code 
BACKED_OUT is purged, the remote LU resends the BACKEDJJUT indi¬ 
cation and the local program receives the return code on a subse¬ 
quent verb. 

The other kinds of incoming information that are purged are: 

• Data, sent by means of the MC_SEND_DATA verb* 

• Map name, sent by means of the MC_SEND_DATA verb* 

• Confirmation request, sent by means of the MC_CONFIRM, 
MC_PREPARE_TO_RECEIVE, or MCJ)EALLOCATE verb. 

• Sync point request, sent by means of the SYNCPT, 

MC_PREPARE_TO_RECEIVE, or MC_DEALLOCATE verb. 

If the confirmation or sync point request was sent in conjunction 
with the MC.DEALLOCATE verb (by means of its TYPE(CONFIRM) or 
TYPE(SYNC_LEVEL) parameter), the deallocation request is also 
purged. 

Incoming information that is not purged is the REQUEST_TO_SEND 
indication. This indication is reported to the program when it 
issues a verb that includes the REQUEST_TO_SEND_RECEIVED parame¬ 
ter . 

5. When REQUEST_TO_SEND_RECEIVED indicates YES, the remote program 
is requesting the local program to enter receive state and thereby 
place the remote program in send state. A program enters receive 
state by means of the MC_RECEIVE_AND_WAIT or 
MC_PREPARE_TO_RECEIVE verb. The partner program enters the cor¬ 
responding send state when .it issues an MC RECEIVE^AND_WAIT or 
MC_RECEIVE_IMMEDIATE verb and receives the SEND indication (on 
the WHAT_RECEIVED parameter). 

6. The program may use this verb for various application-level func¬ 
tions. For example, the program may issue this verb to inform the 
remote program of an error it detected in the data records it 
received, or to reject a confirmation or sync-point request. 

7. MC_SEND_ERROR resets or cancels posting. If posting is active and 
the mapped conversation has been posted, posting is reset. If 
posting is active and the mapped conversation has not been posted* 
posting is canceled (posting will not occur). See the 
MC_POST_ON_RECEIPT verb for more details about posting* 

8. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion. 
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MCJTEST 


Tests the specified mapped conversation for a condition. The return 
code indicates the result of the test. 


HC_TEST 


Supplied Parameters? 

RESOURCE ( variable ) 


[ TEST C POSTED ) 

( REQUEST_TO_SEND_RECEIVED ) 

Returned Parameters: 

RETURN.CODE ( variable ) 
i 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

TEST specifies the condition to be tested. 

• POSTED specifies to test whether the mapped conversation has been 
posted. The return code indicates whether posting has occurred. 

• REQUEST_TO_SEND_RECEIVED specifies to test whether 
REQUEST_TO_SEND notification has been received from the remote 
transaction program. The return code indicates whether the 
notification has been received. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of the test. 
The TEST parameter determines which of the following return codes can 
be returned to the program. 

• If TEST(POSTED) is specified, one of the following return codes is 
returned: 

OK 

— DATA 
— NOT_DATA 
POSTING_NOT ACTIVE 
UNSUCCESSFUL 
ALLOCATION_ERROR 
BACKED_OUT 
DEALLOCATE NORMAL 
DEALLOCATE_ABEND 
FMH_DATA_NOT_SUPPORTED 
MAP_EXECUTION_FAILURE 
MAP_N0T_F0UND 
MAPPING NONSUPPORTED 
PROG ERROR_NO_TRUNC 

prog!error_purging 

RESOURCE_FAILURE_NO_RETRY 

RESOURCE_FAILURE_RETRY 

• If TEST(REQUEST_TO_SEND_RECEIVED) is specified, one of the fol¬ 
lowing return codes is returned: 

OK 

UNSUCCESSFUL 

State Changes (when RETURN CODE indicates OKI: 

None 
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ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• TEST(POSTED) is specified and not supported. 

• TEST(REQUEST_TO_SEND_RECEIVED) is specified and not supported. 

• RESOURCE specifies an unassigned resource ID. 

State Check 

• TEST(POSTED) is specified and the mapped conversation is not in 
receive state. 

• TEST(REQUEST_TO_SEND_RECEIVED) is specified and the mapped con¬ 
versation is not in send* defer* or receive state. 

Notes; 

1. The TEST(POSTED) parameter on this verb is intended to be used in 
conjunction with MC_POST_ON_RECEIPT. The use of 
MC_P0STJ3N__RECEIPT and this verb allows a program to continue its 
processing while waiting for information to become available* 
where the program issues MC_POST_ON_RECEIPT for one or more 
mapped conversations and then issues this verb for each mapped 
conversation to determine when information is available to be 
received. 

2. For TEST(POSTED)* the return code indicates whether posting has 
occurred* as follows: 

• OK indicates posting was active for the mapped conversation 
and it has been posted. Posting is now reset. The subcode of 
the OK return code indicates why the mapped conversation has 
been posted. 

— DATA indicates data is available for the program to 
receive. 

— NOTJDATA indicates information other than data* such as a 
SEND* CONFIRM, or TAKE_SYNCPT indication, is available 
for the program to receive. 

The program should issue MC_RECEIVE_AND_WAIT or 
MC_RECEIVE_IMMEDIATE in order to receive the information. 
The program may use the subcode to determine whether it needs 
to specify the DATA parameter on the MC RECEIVE_AND_WAIT or 
MC_RECEIVE_IMMEDIATE verb. 

• POSTING_NOT_ACTIVE indicates posting is not active for the 
mapped conversation. 

• UNSUCCESSFUL indicates posting is active for the mapped con¬ 
versation and it has not been posted. Posting remains active. 

The remaining return codes indicate posting was active for the 
mapped conversation and it has been posted for the reason indi¬ 
cated by the specific return code. Posting is now reset. 

3. Posting is active for a mapped conversation when 

MC_POST_ON_RECEIPT has been issued for the mapped conversation 
and posting has not been reset or canceled (see the 

MC_POST_ON_RECEIPT verb). 

4. The TEST(REQUEST_TO_SEND_RECEIVED) parameter specifies to test 
whether REQUEST_TG_SEND notification has been received from the 
remote transaction program. The return code indicates whether 
the notification has been received* as follows: 

• OK indicates REQUEST_TO_SEND has been received. The remote 
program has issued MC_REQUEST_TO_SEND* requesting the local 
program to enter receive state and thereby place the remote 
program in send state. A program enters receive state by 
means of the MC_RECEIVE_ANDJ*JAIT or MC_PREPARE_TO_RECEIVE 
verb. The partner program enters the corresponding send 
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state when it issues an MC_RECEIVE_AND_WAIT or 
MC_RECEIVE_IMMEDIATE verb and receives the SEND indication 
(on the WHAT_RECEIVED parameter). 

• UNSUCCESSFUL indicates REQUEST_TO_SEND has not been received. 

References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified mapped conversa¬ 
tion . 
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This section describes the subcategory of conversation verbs called 
type-independent conversation verbs . These verbs are intended for 
use on both mapped conversations and basic conversations. In partic¬ 
ular# the BACKOUT# SYNCPT# and WAIT verbs can be issued against multi¬ 
ple conversations# which can consist of either mapped or basic 
conversations or both. The GET_TYPE verb is issued against a single 
conversation# either mapped or basic. 

The detailed descriptions of the type-independent conversation verbs 
follow. References to verbs that can be either mapped or basic con¬ 
versation verbs are shown with the f, EMC_]" prefix in the verb name. 
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BACKOUT 


Restores all protected resources to their status as of the last syn¬ 
chronization point. Protected resources are those currently allo¬ 
cated to the transaction with a synchronization level of SYNCPT. The 
last synchronization point is either the start of the transaction# or 
the completion of the last successful sync point function if one was 
executed since the start of the transaction. As part of the backout 
function# the LU flushes its send buffers for all protected resources 
that are in send or defer state. 


BACKOUT ; 


Parameters: 

No parameters are defined for this verb. 

State Changes: 

The state of each protected resource at the completion of this verb is 

the same as it was immediately following the last synchronization 

point. 

ABEND Conditions: 

Parameter Check 

This verb is not supported. 

State Check 

At least one protected resource is not in send# defer# receive# 
confirm# sync point# or backed-out state. 

Notes: 

1. The BACKOUT verb causes the local LU to restore all local pro¬ 
tected resources to their status as of the last synchronization 
point# and to send a backed-out indication on all protected con¬ 
versations. (A protected conversation is one that is allocated 
with a synchronization level of SYNCPT.) 

2. Any program throughout the distributed transaction may initiate 
the backout function# that is# may be the first to issue BACKOUT 
since the last synchronization point. It does so when it deter¬ 
mines that an error or exceptional condition exists that requires 
restoring all protected resources to their last synchronization 
point. The program can initiate the backout function as a 
response to a sync point request# or at other times unrelated to a 
sync point request. All other programs interconnected by pro¬ 
tected conversations are informed# by means of the BACKED..OUT 
return code# that the backout function has been initiated. 

3. A program must issue this verb whenever it receives a BACKED_OUT 
return code# in order to extend the backout function to all pro¬ 
tected resources throughout the transaction. 

4. BACKOUT resets or cancels posting. If posting is active and the 
resource has been posted# posting is reset. If posting is active 
and the resource has not been posted# posting is canceled (posting 
will not occur). See the CMCJ1P0ST_0N_RECEIPT verb for details 
about posting of a conversation. 
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GETJTYPE 

Returns the type of resource to which the specified resource ID is 
assigned. 



Supplied Parameters: 

GETJTYPE 

RESOURCE ( variable ) 


Returned Parameters: 


TYPE ( variable ) 


* 

9 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID of the 
resource of which the type is desired. 

Returned Parameters; 

TYPE specifies the variable for returning the type of resource that is 
allocated. The types are: 

• BASIC_CONVERSATION 

• MAPPED_CONVERSATION 

State Changes: 

None 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

State Check 

None 

Notes: 

1. A program that can be processed at either the basic conversation 
protocol boundary or the mapped conversation protocol boundary 
issues this verb in order to determine which category of verbs* 
basic conversation or mapped conversation* it is to use for the 
resource. 
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SYNCPT 


Advances all protected resources to the next synchronization point. 
Protected resources are those currently allocated to the transaction 
with a synchronization level of SYNCPT. As part of the sync point 
function# the LU flushes its send buffers for all protected resources 
that are in send or defer state. 



Returned Parameters: 

SYNCPT 

RETURN.CODE ( variable ) 


REQUEST_TO_SEND_RECEXVED ( variable ) 


1 


Returned Parameters; 

RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of the sync 
point function. 

• OK (sync point is successful) 

• BACKED_OUT 

• HEURISTICJ1IXED 

REQUEST_TO_SEND_RECEXVED specifies the variable in which is returned 
an indication of"whether REQUEST^T0_SEND has been received. The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from one or more remote programs. 

• NO indicates a REQUEST^TQ_SEND notification has not been 
received. 

State Changes (when RETURN CODE indicates OK): 

Reset state is entered when the verb is issued in the defer state 
entered by the preceding CMC_3DEALL0CATE verb. 

Receive state is entered when the verb is issued in the defer state 
entered by the preceding CMC_3PREPARE — TQ_RECEIVE verb# or when the 
verb is issued in the sync point state entered by receipt of 
TAKE_SYNCPT on the preceding tMC_3RECEIVE_AND_WAIT or 

[MC_3RECEIVE_IMMEDIATE verb. 

Send state is entered when the verb is issued in the sync point state 
entered by receipt of TAKE_SYNCPT_J>END on the preceding 
tMC_3RECEIVE_AND_WAIT or [MC_1RECEIVE_IMMEDIATE verb. 

Deallocate state is entered when the verb is issued in the sync point 
state entered by receipt of TAKE_SYNCPT_DEALLOCATE on the preceding 
[MC_3RECEIVE_AND_WAIT or CMC_3RECEIVE_IMMEDIATE verb. 

No state change occurs when the verb is issued in send state. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

State Check 

• A protected resource is not in send# defer# or sync point state. 

• A protected resource is in send state# and the program started but 
did not finish sending a basic conversation logical record. 


Chapter 4. Conversation Verbs 


4-47 








SYNCPT 


Notes: 

1. The program may issue SYNCPT when all protected conversations are 
in send, defer, or sync point state, or a combination of these 
states; however, only one conversation can be in sync point state. 
(A protected conversation is one that is allocated with a synchro¬ 
nization level of SYNCPT.) The remote programs receive the sync 
point request by means of the WHAT_RECEIVED parameter of the 
IMCJRECEIVE_AND_WAIT or [MC_1RECEIVE_IMMEDIATE verb, as follows: 

• On conversations for which the local program is in send state, 
the remote programs receive the TAKE_SYNCPT indication. 

• On conversations in defer state entered by means of a preced¬ 
ing [MC_]PREPARE_TO_RECEIVE verb, the remote programs receive 
the TAKE_SYNCPT_SEND indication. 

• On conversations in defer state entered by means of a preced¬ 
ing [MC_3DEALL0CATE verb, the remote programs receive the 
TAKE — SYNCPT — DEALLOCATE indication. 

2. In a distributed transaction, one program (usually chosen during 
transaction design) is the initiator for sync point processing. 
The other programs each cooperate in propagating the sync point 
processing throughout the distributed transaction. The program 
initiating sync point processing issues SYNCPT, which causes its 
LU to send a sync point request on all of the protected conversa¬ 
tions allocated to the program. Each program receiving the sync 
point request may issue SYNCPT, thereby propagating the request 
throughout the transaction. Mhen all participating programs 
respond to the sync point request by issuing SYNCPT, their LUs and 
the initiating program's LU advance their respective local 
resources to the next synchronization point. 

3. All protected resources, including conversations, allocated to 
the local transaction program must be in send, defer, or sync 
point state when the program issues SYNCPT. If one or more pro¬ 
tected conversations are in receive state, the program may issue 
[MC_]REQUEST_TO_SEND on those conversations to request send con¬ 
trol . 

4. The return code indicates whether the sync point function was suc¬ 
cessful . 

• OK indicates all protected resources have been advanced to 
the next synchronization point. 

• BACKED.OUT indicates all protected resources are to be 

restored to their status as of the last synchronization 

point. The program must issue BACKOUT, which causes the back- 
out function to be performed on all protected resources 
throughout the transaction. 

• HEURISTIC.J1IXED indicates that some protected resources 

throughout the distributed transaction have been advanced to 
the next synchronization point and others have been restored 
to the previous synchronization point as a result of an error 
during the sync point processing. This mixed status of pro¬ 
tected resources occurs when an LU operator intervenes in an 
attempt to recover from the error. See SNA Format and Proto¬ 
col Reference Manual: Architecture Logic for LU Type 6,2 for 
more detaiIs. 

5. Use of sync point ensures consistency of the protected resources 
involved in a distributed transaction. Consistency means that if 
the return code, OK, is returned to the transaction program that 
issued the first SYNCPT verb (called the initiator), OK will also 
have been returned to the dependent SYNCPT verbs issued by every 
other transaction program participating in the distributed log¬ 
ical unit of work. 

Similarly, consistency means that if the BACKED_OUT return code 
is received on any protected conversation in a distributed trans- 
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action* BACKED_OUT Mill be received on all protected conversa¬ 
tions in the distributed transaction. Further* all protected 
local resources that share in the distributed logical unit of work 
Mill be backed out to the most recent point of successful commit¬ 
ment. 

Of particular importance are updates to files or data bases* For 
example* take the case of a fund transfer from an account main¬ 
tained at one node to an account maintained at another node* use 
of SYNCPT Mill ensure* except Mhen heuristic decisions must be 
made* that the debit from one account Mill be credited to the oth¬ 
er. 

6. The processing of unprotected resources is the program’s respon¬ 
sibility. If the sync point function is successful* the program 
should advance all unprotected resources associated Mith the 
transaction to a consistent state. If the sync point function is 
unsuccessful* the unprotected resources should be restored to a 
state consistent Mith the previous synchronization point. 

7. When REQUEST_TO_SEND_RECEIVED indicates YES* one or more remote 
programs are requesting the local program to enter receive state 
and thereby place the remote programs in send state. For each 
resource on Mhich a REQUEST_TO_SEND notification Mas received* 
the notification Mill also be reported to the local program on the 
next resource-specific verb it issues that has the 
REQUEST_TO_SEND_RECEIVED parameter. 

8. References in this verb description to a program being in a par¬ 
ticular state are only in terms of each resource. 
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WAIT 


Waits for posting to occur on any basic or mapped conversation from 
among a list of conversations. Posting of a conversation occurs when 
posting is active for the conversation and the LU has any information 
that the program can receive* such as data* conversation status* or a 
request for confirmation or sync point. 


WAIT 

Supplied Parameters: 

RESOURCE.LXST ( variablel variable2 ... variablen ) 


Returned Parameters: 


RETURN.CODE ( variable ) 


RESOURCE.POSTED ( variable ) 


1 


Supplied Parameters: 

RESOURCE_LIST specifies the variables containing the resource IDs of 
the conversations for which posting is expected. 

• variablel variable? ... variablen are the variables containing 
the individual resource IDs. One or more resource IDs may be 
specified. 

Returned Parameters: 


RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of verb exe¬ 
cution. The type of conversation posted determines which of the 
return codes can be returned to the program. 

• If a mapped conversation is posted* one of the following return 
codes is returned: 

- OK 

— DATA 
— N0T_DATA 
POSTING_NOT ACTIVE 
ALLOCATION_ERROR 
BACKED_OUT 
DEALLOCATE_ABEND 
DEALLOCATE NORMAL 
FMH DATA NONSUPPORTED 

- MAPlEXECUTION_FAILURE 
MAP_NOT_FOUND 
MAPPING_NOT_SUPPORTED 
PR0G_ERR0R N0_TRUNC 
PROG_ERRORlPURGING 
RESOURCE_FAILURE_NO_RETRY 
RESOURCE_FAILURE_RETRY 

• If a basic conversation is posted* one of the following return 
codes is returned: 

OK 

— DATA 
— NOT.DATA 
POSTING_NOT_ACTIVE 
ALLOCATION_ERROR 
BACKED_OUT 

DEALLOCATE_ABEND_PROG 

DEALLOCATE_ABEND_SVC 

DEALLOCATE_ABEND_TIMER 

DEALLOCATE_NORMAL 

PR0G_ERR0R_N0_TRUNC 

PR0G_ERR0R_PURGING 

PR0G_ERR0R TRUNC 
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SVC_ERROR_NO_TRUNC 
SVC_ERROR_PURGING 
SVC_ERR0R TRUNC 
RESOURCE_FAILURE_NO RETRY 
RESOURCE_FAILURE_RETRY 

RESOURCE_P0STED specifies the variable in which the resource ID of the 
posted conversation is returned to the program. 

State Changes (when RETURN CODE indicates OK); 

None 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE_LIST specifies an unassigned resource ID. 

State Check 

None 

Notes: 

1. This verb is intended to be used in conjunction with 
[MC_3P0ST_0N_RECEIPT. The use of (MC_3P0ST_0N_RECEIPT and this 
verb allows a program to perform synchronous receiving from mul¬ 
tiple conversations* where the program issues 
tMC_]POST_ON_RECEIPT for each of the conversations and then 
issues this verb (for each conversation) to wait until informa¬ 
tion is available to be received on the conversations. 

2. The RE$OURCE_lIST parameter may specify any combination of basic 
and mapped conversations. Posting for each conversation may be 
active or not active. This verb waits for posting to occur only 
on the conversations for which posting is active* When a conver¬ 
sation is posted* the resource ID of the posted conversation is 
returned to the program by means of the RESOURCE_POSTED parame¬ 
ter. 

3. The return code indicates whether posting has occurred* as fol¬ 
lows: 

• OK indicates posting was active for a conversation and it has 
been posted. Posting is now reset for the conversation. The 
subcode of the OK return code indicates why the conversation 
has been posted. 

- DATA indicates data is available for the program to 
receive. 

— N0T_DATA indicates information other than data* such as a 
SEND* CONFIRM, or TAKE_SYNCPT indication* is available 
for the program to receive. 

The program should issue tMC_3RECEIVE_AND_WAIT or 
tMC_3RECEIVE_IMMEDIATE in order to receive the information. 
The program may use the subcode to determine whether it needs 
to specify the DATA parameter on the tMC_3RECEIVE_AND_WAIT or 
[MC_3RECEIVE — IMMEDIATE verb. 

• POSTING_NQT_ACTIVE indicates posting is not active for any 
and all of the conversations. 

The remaining return codes indicate posting was active for a con¬ 
versation and it has been posted for the reason indicated by the 
specific return code. Posting is now reset for the conversation. 

4. Posting is active for a conversation when IMC_3P0ST_0N_RECEIPT 
has been issued for the conversation and posting has not been 
reset or canceled (see the [MC_3P0ST_0N_RECEIPT verb). 
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This section describes the subcategory of conversation verbs called 
basic conversation verbs . These verbs are intended for use by LU 
services programs. The LU services programs can provide end-user 
services or protocol boundaries for end-user application transaction 
programs. Examples of LU services programs are: 

• The LU services component programs that process mapped conversa¬ 
tion verbs and control-operator verbs. These verbs define the LU 
6.2 protocol boundary for mapped conversations and the control 
operator. 

• SNA service transaction programs. These programs provide 
end-user protocol boundaries that are defined by the specific IBM 
product implementations of the service programs. Refer to the IBM 
product publications for a description of the SNA service pro¬ 
grams and their protocol boundaries that each product provides. 
The names of some SNA service transaction programs that have gen¬ 
eral applicability are listed in "Appendix D. List of SNA Service 
Transaction Programs”. 

The detailed descriptions of the basic conversation verbs follow. 

Note: Every conversation is either a basic or mapped conversation. 

The basic conversation verbs can be used for operations on both types. 
The mapped conversation verbs can be used for operations only on a 
mapped conversation. The capability to use basic conversation verbs 
on mapped conversations is provided for implementation of a mapped 
conversation LU services component program. Throughout the 
descriptions of the basic conversation verbs# references to a basic 
conversation or mapped conversation are made only when it is necessary 
to make a distinction between them. Otherwise# references are made 
simply to conversations. 
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ALLOCATE 


Allocates a session between the local LU and a remote LU# and on that 
session allocates a basic or mapped conversation between the local 
program and a remote program, A resource ID is assigned to the con¬ 
versation. This verb is issued prior to any verbs that refer to the 
conversation. 


i 


ALLOCATE 


Supplied Parameters; 

LU.NAHE ( OWN ) 

( OTHER ( variable ) ) 

MODE_NAME ( variable ) 

TPN ( variable ) 


[ TYPE C BASIC CONVERSATION ) 

C MAPPED_CONVERSAT1ON ) 

1 C WHEN SESSION ALLOCATED ) 
RETURN.CONTROL C DELAYED.ALLOCATION PERMITTED ) 
( IMMEDIATE ) 

( NONE ) 

SYNCJLEVEL ( CONFIRM ) 

C SYNCPT ) 


( NONE ) 

SECURITY ( SAME ) 

( PGM C USER.ID ( variable ) PASSWORD ( variable ) 
PROFILE ( variable ) ) 1 

[ PIP ( NO ) 1 

( YES ( variablel variable2 ... variablen ) ) j 


Returned Parameters: 
resource ( variable ) 
RETURN.CODE ( variable ) 
t 


Supplied Parameters: 

LU_NAME specifies the name of the remote LU at which the remote trans¬ 
action program is located. This LU name is any name by which the 
local LU knows the remote LU for the purpose of allocating a conversa¬ 
tion. The local LU transforms this locally-known LU name to an LU 
name used by the network* if the names are different. 

• OWN specifies that the remote program is located at the same LU as 
the local program. 

• OTHER specifies that the remote program is located at another LU. 
The specified variable contains the LU name. 

MODE_NAME specifies the mode name designating the network properties 
for the session to be allocated for the conversation. The network 
properties include* for example* the class of service to be used* and 
whether data is to be enciphered or translated to ASCII before it is 
sent. The SNA-defined mode name* SNASVCMG* may be specified* but only 
by an LU services program. 
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TPN specifies the name of the remote transaction program to be con¬ 
nected at the other end of the conversation. A transaction program 
that has the appropriate privilege may specify the name of an SNA 
service transaction program. Privilege is an identification that a 
product or installation defines in order to differentiate LU services 
transaction programs from other programs# such as application trans¬ 
action programs. (See "Appendix D. List of SNA Service Transaction 
Programs" for more details about SNA service transaction program 
names.) 

TYPE specifies the type of conversation to be allocated. 

• BASIC_CONVERSATION specifies to allocate a basic conversation. 

• MAPPED_CONVERSATION specifies to allocate a mapped conversation. 
This argument is used in support of mapped conversation verbs. It 
may be specified only by a mapped conversation LU services pro¬ 
gram. 

RETURN_CONTROL specifies when the local LU i s to return control to the 
local program# in relation to the allocation of a session for the con¬ 
versation. An allocation error resulting from the local LU’s failure 
to obtain a session for the conversation is reported either on this 
verb or a subsequent verb# depending on the argument specified for 
this parameter. An allocation error resulting from the remote LU v s 
rejection of the allocation request is reported on a subsequent verb. 

• MHEN_SESSION_ALLOCATED specifies to allocate a session for the 
conversation before returning control to the program. An error in 
allocating a session is reported on this verb. 

• DELAYED_ALLOCATION_PERMITTED specifies to allocate a session for 
the conversation after returning control to the program. An error 
in allocating a session is reported on a subsequent verb. 

• IMMEDIATE specifies to allocate a session for the conversation if 
a session is immediately available# and return control to the pro¬ 
gram with a return code indicating whether a session is allocated. 

— A return code of OK indicates a session is immediately avail¬ 
able and is allocated for the conversation. A session is 
immediately available when it is active# it is not allocated 
to another conversation# and the local LU is the contention 
winner for the session. 

— A return code of UNSUCCESSFUL indicates a session is not imme¬ 
diately available. Allocation is not performed. 

An error in allocating a session that is immediately available is 
reported on this verb. 

SYNC_LEVEL specifies the synchronization level that the local and 
remote programs can use on this conversation. 

• NONE specifies that the programs will not perform confirmation or 
sync point processing on this conversation. The programs will not 
issue any verbs and will not recognize any returned parameters 
relating to these synchronizat i on functions. 

• CONFIRM specifies that the programs can perform confirmation 
processing but not sync-point processing on this conversation. 
The programs may issue verbs and will recognize returned parame¬ 
ters relating to confirmation# but they will not issue any verbs 
and will not recognize any returned parameters relating to sync 
point. 

• SYNCPT specifies that the programs can perform both confirmation 
and sync-point processing on this conversation. The programs may 
issue verbs and will recognize returned parameters relating to 
confirmation or sync point. For sync-point processing# a conver¬ 
sation allocated with this synchronization level is a protected 
resource. 
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SECURITY specifies access security information that the remote LU 
uses to verify the identity of the end-user and validate access to the 
remote program and its resources. The access security information 
consists of a user ID, a password, and a profile. 

• NONE specifies to omit access security information on this allo¬ 
cation request. 

• SANE specifies to use the user ID and profi le (if present) from 
the allocation request that initiated execution of the local pro¬ 
gram. The password (if present) is not used; instead, the user ID 
is indicated as being already verified. If the allocation request 
that initiated execution of the local program contained no access 
security information, then access security information is omitted 
on this allocation request. 

• PGN specifies to use the access security information that the 
local program provides on this parameter. The local program pro¬ 
vides the information by means of the following arguments: 

— USER_ID specifies the variable containing the user ID. The 
remote LU uses this value and the password to verify the iden¬ 
tity of the end-user making the allocation request. In addi¬ 
tion, the remote LU may use the user ID for auditing or 
accounting purposes, or it may use the user ID, together with 
the profile (if present), to determine which remote programs 
the local program may access and which resources the remote 
program may access. 

— PASSWORD specifies the variable containing the password. The 
remote LU uses this value and the user ID to verify the iden¬ 
tity of the end-user making the allocation request. 

— PROFILE specifies the variable containing the profile. The 
remote LU may use this value, in addition to or in place of 
the user ID, to determine which remote programs the local pro¬ 
gram may access, and which resources the remote program may 
access. 

Specifying a null value for any of the access security arguments 
is equivalent to omitting the argument. 

PIP specifies program initialization parameters for the remote pro¬ 
gram. 

• NO specifies that PIP data is not present. 

• YES specifies that PIP data is present. 

— variablel variables ... variablen contain the PIP data to be 
sent to the remote program. The PIP data consists of one or 
more subfields, each of which is specified by a separate vari¬ 
able; variables 1 through n correspond to subfields 1 through 
n. If a variable is omitted in the PIP parameter or it is of 
null value, the corresponding PIP subfield is made to be of 0 
length. The number of PIP subfields must agree with the num¬ 
ber of PIP variables specified on the remote program's PROC 
statement (see "Transaction Program Structure and Execution" 
i n Chapter 3). 

Returned Parameters: 

RESOURCE specifies the variable in which the resource ID is to be 
returned. The length and actual format of the resource ID is product 
dependent. The resource ID is returned to the program when the return 
code is either OK or ALLOCATION_ERROR. 

RETURN_CODE specifies the variable in which a return code is returned 
to the~ local program. The return code indicates the result of verb 
execution. The RETURN_CQNTROL parameter determines which of the fol¬ 
lowing return codes can be returned to the program* 

• If RETURN_CONTRQL(WHEN_SESSION_ALLOCATED) is specified, one of 
the following return codes is returned: 
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- OK 

— ALLOCATION ERROR (with one of the following subcodes) 

— ALLOCATION_FAILURE_NO_RETRY 
— ALLOCATION_FAILURE_RETRY 
— SYNC_LEVEL_NOT_SUPPORTED_BYJ.U 
— PARAMETER_ERRGR (for the following reasons) 

— Invalid LU name 
— Invalid mode name 

• If RETURN — CONTROL(DELAYED_ALLOCATION — PERMITTED) is specified, 
one of the following return codes is returned: 

OK 

— PARAMETER_ERROR (for one of the following reasons) 

— Invalid LU name 
— Invalid mode name 

• If RETURN_CONTRQL(IMMEDIATE) is specified, one of the following 
return codes is returned: 

- OK 

ALLOCATION ERROR (with the following subcode) 

— SYNC_LEVEL_NOT_SUPPORTED_BY_LU 

- PARAMETER_ERROR (for one of the following reasons) 

— Invalid LU name 

— Invalid mode name 

UNSUCCESSFUL (for the following reason) 

— Session not immediately available 

State Changes (when RETURN CODE indicates OK): 

Send state is entered* 

ABEND Conditions; 

Parameter Check 

• LU_NAME(OWN) is specified and not supported* 

• M0DE_NAME specifies SNASVCMG and the local program is not an LU 
services program. 

• TPN specifies an SNA service transaction program name and the 
local program does not have the appropriate privilege to allocate 
a conversation to an SNA service program* 

• TPN specifies a null (0 length) value. 

• TYPE(BASIC_CONVERSATION) is specified and the local program does 
not have basic conversation support defined* 

• TYPE(MAPPED_CQNVERSATION) is specified and the local program is 
not a mapped conversation LU services program. 

• RETURN_CONTROL(DELAYED_ALLOCATION_PERMITTED) is specified and 
not supported. 

• RETURN_C0NTR0L(IMMEDIATE) is specified and not supported* 

• SYNC_LEVEL(SYNCPT) is specified and not supported. 

• SECURITY(SAME) is specified and not supported. 

• SECURITY(PGM(USER_ID(variable) PASSW0RD(variable))) is specified 
and not supported. 

• SECURITY(PGM(PROFILE(variable))) is specified and not supported. 

• PIP(YES(variable)) is specified and not supported. 

State Check 
None 
Notes; 

1. This verb is used by a transaction program to allocate a basic 
conversation. It is also used by an LU services component program 
to allocate either a basic conversation or a mapped conversation, 
depending on the function that the component program provides. 
For example, a component program that processes control operator 
verbs uses this verb to allocate a basic conversation, and a com¬ 
ponent program that processes mapped conversation verbs uses this 
verb to allocate a mapped conversation. 
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2. Depending on the product* the LU may send the allocation request 
to the remdte LU as soon as it allocates a session for the conver¬ 
sation. Alternatively* the LU may buffer the allocation request 
until it accumulates from the PIP parameter of this verb or from 
one or more subsequent SEND_DATA verbs a sufficient amount of 
information for transmission* or until the local program issues a 
subsequent verb other than SEND_DATA that explicitly causes the 
LU to flush its send buffer. The amount of information that is 
sufficient for transmission depends on the characteristics of the 
session allocated for the conversation* and can vary from one ses¬ 
sion to another. 

3. The local program can ensure that the remote program is connected 
as soon as possible by issuing FLUSH immediately after ALLOCATE. 

4. Two LUs connected by a session may both attempt to allocate a con¬ 

versation on the session at the same time. This is called con¬ 
tention. Contention is resolved by making one LU the contention 
winner of the session and the other LU the contention loser of the 
session. The contention-winner LU allocates a conversation on a 
session without asking permission from the contention-loser LU. 
Conversely* the contention-loser LU requests permission from the 
contention-winner LU to allocate a conversation on the session* 
and the contention-winner LU either grants or rejects the 

request. 

5. If the program issues ALLOCATE with the parameter 

RETURN_CONTROL(DELAYED_ALLOCATION_PERMITTED)* the LU delays 
allocation of the session until it flushes its send buffer. At 
that time the LU allocates the session and transmits the allo¬ 
cation request to the remote LU. The program is unaffected by the 
delayed allocation of the session* with one exception: bJhen the 
LU allocates a contention-loser session* it does so by transmit¬ 
ting the allocation request and then waiting for information to 
arrive before returning control to the program. This can affect 
the sequence of the verbs that the program can issue. 

For example* suppose the program has the following sequence of 
verbs: 

ALLOCATE with RETURN_CONTROL(DELAYED_ALLOCATION_PERMITTED) 
PREPARE_TO_RECEIVE with TYPE(FLUSH) 

REQUEST_TO_SEND 

In this example* assume the program is using REQUEST_TO_SEND to 
prompt the remote program to begin sending information* instead 
of requesting send control. However* if the LU allocates a con¬ 
tention-loser session (and an allocation error or resource fail¬ 
ure does not occur)* control is not returned to the program after 
it issues the PREPARE_TO_RECEIVE until the remote program sends 
some information. If the remote program waits for the 
REQUEST_TO_SEND notification before sending any information* a 
deadlock condition occurs. This deadlock can be avoided by issu¬ 
ing the ALLOCATE with either RETURN_CONTROL 
(WHEN_SESSION_ALLOCATED) or RETURN_CONTROL (IMMEDIATE). 

6. SYNC_LEVEL(SYNCPT) permits use of the SYHCPT and BACKOUT verbs 
and the Resynchronization transaction program (an SKA service 
transaction program)* to aid in maintaining consistency across 
all protected resources within a distributed logical unit of 
work. The Resynchronization program performs sync point resyn¬ 
chroni zation* which maintains this consistency when session fail¬ 
ure and reinitiation occurs. See SNA Format and Protocol 
Reference Manual: Architecture Logic for LU Type 6.2 for more 
details of sync point resynchronization. 

7. Each LU indicates at session activation time whether it will 
accept LU security parameters on allocation requests the partner 
LU sends. If the remote LU will not accept any security parame¬ 
ters from the local LU* and the local program specifies SECURI- 
TY(SAME) or SECURITY(PGM(...)), the local LU downgrades the 
specification to SECURITY(NONE). Similarly* if the remote LU 
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will not accept the local LU f s verification of the user ID and 
password* and the local program specifies SECURITY(SAME)> the 
local LU downgrades the specification to SECURITYCHONE). 

8. The remote program is connected to the other end of the conversa¬ 
tion in receive state. 

9. The program uses the resource ID* returned to the program on the 
RESOURCE parameter* on all subsequent basic conversation verbs it 
issues for this conversation. 

10. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the allocated conversation. 
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CONFIRM 


Sends a confirmation request to a remote transaction program and waits 
for a reply. This verb allows the local and remote programs to syn¬ 
chronize their processing with one another. The LU flushes its send 
buffer as a function of this verb. 



Supplied Parameters: 

CONFIRM 

RESOURCE ( variable ) 


Returned Parameters: 

RETURN.CODE ( variable ) 

REQUEST_TO_SEND_RECEIVED C Variable ) 


; 


Supplied Parameters? 

RESOURCE specifies the variable containing the resource ID. The con¬ 
versation must be allocated with a synchronization level of CONFIRM or 
SYNCPT. 

Returned Parameters; 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. 

• OK (remote program replied CONFIRMED) 

• ALL0CATI0N_ERR0R 

• BACKED_OUT 

• DEAUOCATE_ABEND_PROG 

• DEALLOCATE_ABEND_SVC 

• DEALLOCATE_ABEND_TIMER 

• PROG_ERROR_PURGING 

• RESOURCE_FAILURE_NO_RETRY 

• RESOURCE_FAILURE_RETRY 

• SVC_ERROR_PURGING 

REQUEST_TO_SEND_RECEIVED specifies the variable in which is returned 
an indication of whether REQUEST_TO_SEND has been received. The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued REQUEST_TO_SEND> requesting the local program to enter 
receive state and thereby place the remote program in send state. 

• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

State Changes (when RETURN CODE indicates OK): 

Receive state is entered when the verb is issued in defer state fol¬ 
lowing PREPARE_TO_RECEIVE. 

Reset state is entered when the verb is issued in defer state follow¬ 
ing DEALLOCATE. 

No state change occurs when the verb is issued in send state. 

ABEND Conditions: 

Parameter check 

• The conversation was allocated with SYNC_LEVEL(NONE). 

• RESOURCE specifies an unassigned resource ID. 
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State Check 

• The conversation is not in send or defer state. 

• The conversation is in send state* and the program started but did 
not finish sending a logical record. 

Notes; 

1. The program may use this verb for various application-level func¬ 
tions. For example: 

• The program may issue this verb immediately following an 
ALLOCATE in order to determine whether the allocation of the 
conversation is successful before sending any data. 

• The program may issue this verb as a request for acknowledge¬ 
ment of data it sent to the remote program. The remote pro¬ 
gram may respond by issuing CONFIRMED as an indication that it 
received and processed the data without error* or by issuing 
SEND_ERROR as an indication that it encountered an error. 

2. When REQUEST_TO_SEND_RECEIVED indicates YES, the remote program 
requests the local program to enter receive state and thereby 
place the remote program in send state. A program enters receive 
state by means of the PREPARE_TQ_RECEIVE or RECEIVE_AND_UAIT 
verb. The partner program enters the corresponding send state 
when it issues a RECEIVE_AND_WAIT or RECEIVE_IMMEDIATE verb and 
receives the SEND indication Con the WHAT_RECEIVED parameter). 

3. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Sends a confirmation reply to the remote transaction program. This 
verb allows the local and remote programs to synchronize their proc¬ 
essing with one another. The local program can issue this verb when 
it receives a confirmation request (see the WHAT RECEIVED parameter 
of the RECEIVE_AND_WAIT or RECEIVE_IMMEDIATE verb)7 



Supplied Parameters: 

CONFIRMED 

resource ( variable ) 


1 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

State Changes; 

Receive state is entered when CONFIRM was received on the preceding 
RECEIVE_AND_WAIT or RECEIVE_IMMEDIATE. 

Send state is entered when CONFIRM_SEND was received on the preceding 
RECEIVE_AND_WAIT or RECEIVE_IMMEDIATE. 

Deallocate state is entered when CONFIRM_DEALLOCATE was received on 
the preceding RECEIVE_AND_WAIT or RECEIVE_IMMEDIATE. 

ABEND Conditions: 

Parameter Check 

RESOURCE specifies an unassigned resource ID. 

State Check 

The conversation is not in confirm state. 

Notes: 

1. The program can issue this verb only as a reply to a confirmation 
request; the verb cannot be issued at any other time. 

2. The program may use this verb for various application-level func¬ 
tions. For example* the remote program may send data followed by 
a confirmation request. When the local program receives the con¬ 
firmation request* it may issue this verb as an indication that it 
received and processed the data without error. 

3. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Deallocates the specified conversation from the transaction program* 
The deallocation can be either completed as part of this verb* or 
deferred until the program issues a FLUSH* CONFIRM* or SYNCPT verb* 
When it is completed as part of this verb it can include the function 
of the FLUSH or CONFIRM verb. The resource ID becomes unassigned when 
deallocation is complete. 


Supplied Parameters: 


DEALLOCATE 


RESOURCE ( variable ) 


( SYNC LEVEL J 
( FLUSH ) 

( CONFIRM ) 

TYPE C ABEND_PROG ) 

( ABEND SVC ) 

( ABENDJTIMER ) 
( LOCAL ) 


LOGJDATA C NO ) 

( YES ( variable 


) ) 


Returned Parameters: 
RETURN_CODE ( variable ) 

t 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID of the con¬ 
versation to be deallocated. 

TYPE specifies the type of deallocation to be performed. 

• SYNC_LEVEL specifies to perform deallocation based on the syn¬ 
chronization level allocated to this conversation: 

— If SYNC_LEVEL(NONE)* execute the function of the FLUSH verb 
and deallocate the conversation normally. 

If SYNC^LEVEL(CONFIRM), execute the function of the CONFIRM 
verb and if it is successful (as indicated by a return code of 
OK on this DEALLOCATE verb)* deallocate the conversation 
normally* if it is not successful* the state of the conversa¬ 
tion is determined by the return code. 

— If SYNC_LEVEL(SYNCPT)* defer the deallocation until the pro¬ 
gram issues a SYNCPT* or the program issues a CONFIRM or FLUSH 
for this conversation. If the SYNCPT or CONFIRM is successful 
(as indicated by a return code of OK on that verb) or FLUSH is 
issued* the conversation is then deallocated normally; other¬ 
wise* the state of the conversation is determined by the 
return code. 

• FLUSH specifies to execute the function of the FLUSH verb and 
deallocate the conversation normally. 

• CONFIRM specifies to execute the function of the CONFIRM verb and 
if it is successful (as indicated by a return code of OK on this 
DEALLOCATE verb)* deallocate the conversation normally; if it is 
not successful* the state of the conversation is determined by the 
return code. 

• ABEND_PROG* ABEND_SVC* or ABENDJTIMER specifies to execute the 
function of the FLUSH verb when the conversation is in send or 
defer state* and deallocate the conversation abnormally. 
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Logical-record truncation can occur when the conversation is in 
send state; data purging can occur when it is in receive state* 

• LOCAL specifies to deallocate the conversation locally. This 
type of deallocation must be specified if# and only if# the con¬ 
versation is in deallocate state. Deallocate state is entered 
when the program receives on a previously issued verb a return 
code indicating the conversation has been deallocated (see "Re¬ 
turn Codes" on page 4-99). 

The execution of the FLUSH or CONFIRM function as part of this verb 
includes the flushing of the LU f s send buffer. Ulhen# instead# the 
deallocation is deferred# the LU also defers flushing its send buffer 
until the program issues a subsequent verb for this conversation. 

LOG_DATA specifies whether product-unique error information is to be 
placed in the system error logs of the LUs supporting this conversa¬ 
tion. This parameter can be specified only when TYPE(ABEND PROG), 
TYPE(ABEND_SVC)# or TYPE(ABEND_TIMER) is also specified. 

• NO specifies that no error information i s to be placed in the sys¬ 
tem error logs. 

• YES specifies that product-unique error information i s to be 
placed in the system error logs of the local and remote LUs. The 
specified variable contains the product-unique error information# 
in the format of the Error Log GDS variable. See SNA Format and 
Protocol Reference Manual; Architecture Logic for LU Type 6.2 for 
a definition of the Error Log GDS variable. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. The TYPE parameter determines which of the following 
return codes can be returned to the program. 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 

allocated to this conversation is NONE# or TYPE(FLUSH)# 
TYPEC ABEND_PRQG)# TYPE(ABEND_SVC), TYPECABEND_TIMER)# or 

TYPECLOCAL) is specified; the following return code is returned: 

— OK (deallocation is complete) 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this conversation is CONFIRM# or TYPE(CONFIRM) is 
specified# one of the following return codes is returned: 

— OK (deallocation is complete) 

ALLOCATIQN_ERROR 

DEALLOCATE_ABEND_PROG 

DEALLQCATE_ABEND_SVC 

DEALLOCATE_ABEND_TIMER 

PROG_ERROR_PURGING 

SVC_ERRGR_PURGING 

RESOURCE_FAILURE_NO_RETRY 

RESOURCE_FAILURE_RETRY 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this conversation is SYNCPT# the following return 
code is returned: 

- OK (deallocation is deferred) 

State Changes (when RETURN CODE indicates OK): 

Defer state is entered when TYPE(SYNC_LEVEL) is specified and the syn¬ 
chronization level is SYNCPT. 

Reset state is entered when TYPE(FLUSH)# TYPE(CONFIRM), TYPE(LOCAL)# 
TYPE(ABENDJPROG)# TYPE(ABEND_SVC)# or TYPE(ABEND_TIMER) is specified; 
or when TYPE(SYNC LEVEL) is specified and the synchronization level 
is NONE or CONFIRM? 
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ABEND Conditions: 

Parameter check 

• RESOURCE specifies an unassigned resource ID. 

• TYPECCONFIRM) is specified and the conversation is allocated with 
SYNC LEVELCNONE). 

• TYPEC ABEND_SVC). or TYPE<ABENDJTIMER) is specified and not sup¬ 
ported. 

• LOG_DATA is specified and not supported. 

State Check 

• TYPECFLUSH), TYPECCONFIRM), or TYPECSYNC_LEVEL) is specified and 
the conversation is not in send state. 

• TYPECFLUSH), TYPECCONFIRM), or TYPECSYNCJ.EVEL) is specified, the 
conversation is in send state, and the program started but did not 
finish sending a logical record. 

• TYPECABEND_PROG), TYPECABEND_SVC), or TYPECABEND_TIMER) is speci¬ 
fied and the conversation is not in send, defer, receive, confirm, 
or sync-point state. 

• TYPECLOCAL) is specified and the conversation is not in deallo¬ 
cate state. 

Notes: 

1. When the deallocation is deferred Csee the TYPE parameter), the LU 
buffers the deallocation information to be sent to the remote LU 
until the local program issues a verb that causes the LU to flush 
its send buffer. 

2. The TYPECSYNC_LEVEL) parameter is intended to be used by the 
transaction program in order to deallocate the conversation based 
on the synchronization level allocated to the conversation. 

• If the synchronization level is NONE, the conversation is 
unconditionally deallocated. 

• If the synchronization level is CONFIRM, the conversation is 
deallocated when the remote program responds to the confirma¬ 
tion request by issuing CONFIRMED. The conversation remains 
allocated when the remote program responds to the confirma¬ 
tion request by issuing SEND_ERROR. 

• If the synchronization level is SYNCPT, the conversation is 
deallocated when the local program subsequently issues SYNCPT 
and all programs throughout the transaction, connected to 
conversations having the synchronization level of SYNCPT, 
respond to the sync point request by issuing SYNCPT. The con¬ 
versation remains allocated when the remote program responds 
to the sync point request by issuing SEND_ERROR, or one or 
more programs respond by issuing BACKGUT. 

3. The TYPECFLUSH) parameter is intended to be used by the trans¬ 
action program in order to unconditionally deallocate the conver¬ 
sation regardless of its synchronization level. TYPECFLUSH) is 
functionally equivalent to: 

• TYPECSYNC_LEVEL) with a synchronization level of NONE. 

• TYPECSYNC_LEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the FLUSH verb. 

4. The TYPECCONFIRM) parameter is intended to be used by the trans¬ 
action program in order to conditionally deallocate the conversa¬ 
tion, depending on the remote program's response, when the 
synchronization level is CONFIRM or SYNCPT. TYPECCONFIRM) is 
functionally equivalent to: 

• TYPECSYNC_LEVEL) with a synchronization level of CONFIRM. 

• TYPECSYNC^LEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the CONFIRM verb. 
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The conversation is deallocated when the remote program responds 
to the confirmation request by issuing CONFIRMED* The conversa¬ 
tion remains allocated when the remote program responds to the 
confirmation request by issuing SEND_ERROR. 

5. The TYPECABEND_PROG), TYPECABEND_SVC)* and TYPECABEND_TIMER) 
parameters are intended to be used in order to unconditionally 
deallocate^ the conversation regardless of its synchronization 
level and its current state* Specifically: 

• The TYPECABEND_PROG) parameter is intended to be used by a 
transaction program when it detects an error condition that 
prevents further useful communications, that is* communi¬ 
cations that would lead to successful completion of the 
transaction* The specific use and meaning of ABEND_PROG are 
program-defined. 

• The TYPECABEND_SVC) parameter is intended to be used by an LU 

services component* such as one that processes mapped conver¬ 
sation verbs* when it detects an error condition caused by its 
peer LU services component in the remote LU* An example is a 
format error in control information sent by the peer LU serv¬ 
ices component* The specific use and meaning of ABEND_SVC are 
product-defined* ~ 

• The TYPECABEND_TIMER) parameter is intended to be used by an 
LU services component* such as one that processes mapped con¬ 
versation verbs* when it detects or is informed of a condition 
that requires the conversation to be deallocated without fur¬ 
ther communications* For example* too much time elapses 
without receiving any information* or an operator prematurely 
ends program execution* The specific conditions and the 
means by which the LU services component detects or is 
informed of the conditions are product-defined. The specific 
use and meaning of ABEND_TIMER are also product-defined. 

6. The TYPE(LOCAL) parameter is intended to be used by the trans¬ 
action program in order to complete the program 1 s deallocation of 
the conversation after receiving an indication that the conversa¬ 
tion has been deallocated from the session* an indication such as 
a DEALLOCATE_NQRMAl or RESQURCE_FAILURE_RETRY return code* 

7. The remote transaction program receives the deallocate notifica¬ 
tion by means of a return code or what-received indication* as 
follows: 

• DEALLOCATE_NORMAL return code: The local program specified 
either TYPECFLUSH)* TYPECSYNC^LEVEL) and the synchronization 
level is NONE; or TYPECSYNCJ.EVEL), the synchronization level 
is SYNCPT* and the local program subsequently issued FLUSH. 

• CONFIRM_DEALLOCATE what-received indication: The local pro¬ 
gram specified either TYPE(CONFIRM)* TYPECSYNC_LEVEL) and the 
synchronization level is CONFIRM* or TYPECSYNC_LEVEL)* the 
synchronization level is SYNCPT* and the local program subse¬ 
quently issued CONFIRM* 

• TAKE_SYNCPT_DEALLOCATE what-received indication: The local 
program specified TYPECSYNC_LEVEL) * the synchronization level 
is SYNCPT* and the local program subsequently issued SYNCPT. 

• DEALLOCATE_ABEND_PROG* DEALLOCATE_ABEND_SVC, or DEALLO- 

CATE_ABEND_TIMER return code: The local program specified* 
respectively, TYPECABENDJ>ROG)* TYPECABEND_SVC)* or 

TYPECABEND_TIMER)* with the following exception: If the 
remote program has issued a SEND_ERROR in receive state* a 
DEALLOCATE NORMAL return code is reported instead of one of 
the DEALLOCATE_ABEND return codes. 

8. DEALLOCATE with TYPECABEND_PROG)* TYPECABEND_SVC)* or 

TYPECABEND_TIMER) resets or cancels posting. If posting is 
active and the conversation has been posted* posting is reset. If 
posting is active and the conversation has not been posted* post- 
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ing is canceled (prosting will not occur). See the P0ST_0N_RECEIPT 
verb for more details about posting. 

9. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Flushes the local LU's send buffer. The LU sends any information it 
has buffered to the remote LU. Information the LU buffers can come 
from ALLOCATE, DEALLOCATE, SEND_DATA» PREPARE_TO_RECEIVE, or 
SEND_ERROR. Refer to the descriptions of these verbs for details of 
the information the LU buffers and when buffering occurs. 


FLUSH 


Supplied Parameters: 
RESOURCE ( variable ) 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

State Changes: 

Receive state is entered when the verb is issued in defer state fol- 

lowing PREPARE_TO_RECEIVE. 

Reset state is entered when the verb is issued in defer state follow** 

ing DEALLOCATE. 

No state change occurs when the verb is issued in send state. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

State Check 

The conversation is not in send or defer state. 

Notes.! 

1. This verb is useful for optimization of processing between the 
local and remote programs. The LU normally buffers the data from 
consecutive SEND_DATAs until it has a sufficient amount for 
transmission. At that time it transmits_the buffered data. How¬ 
ever, the local program can issue FLUSH in order to cause the LU 
to transmit the buffered data. In this way, the local program can 
minimize the delay in the remote program's processing of the data. 

2. This verb can be issued after DEALLOCATE with TYPE(SYNC_LEVEL) 
when the synchronization level for the conversation is SYNCPT. 
The effect to the remote program is the same as issuing DEALLOCATE 
with TYPE(FLUSH). The conversation is deallocated at the com¬ 
pletion of the FLUSH verb. 

3. This verb can be issued after PREPARE_TO_RECEIVE with 
TYPE(SYNC_LEVEL) when the synchronization level for the conversa¬ 
tion is SYNCPT. The effect to the remote program is the same as 
issuing PREPARE_TO_RECEIVE with TYPE(FLUSH). The conversation 
enters receive state at the completion of the FLUSH verb. 

4. The LU flushes its send buffer only when it has some information 
to transmit. If the LU has no information in its send buffer, 
nothing is transmitted to the remote LU. 

5. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Returns information pertaining to the specified conversation. 


GET.ATTRXBUTES 


supplied Parameters? 

RESOURCE C variable ) _ 

Returned Parameters: 

[ OWN_FULLY_QUALIFXED_LU_NAME ( variable ) ] 

[ partmer_lu_name C variable ) ] 

[ PARTNER_FULLY_QUALIFIED_LU_NAME ( variable ) ] 
[ MODE_NAME ( variable ) ] 

[ SYNC.LEVEL ( variable ) ] 

[ securxty_user_xd ( variable ) ] 

[ SECURXTY.PROFXLE ( variable ) ] 

[ LUU.XDENTXFXER ( variable ) ] 

[ CONVERSATXON_CORRELATOR ( variable ) ] 
i 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID of the con¬ 
versation of which the attributes are desired. 

Returned Parameters: 

OWN_FULLY_QUALIFIED_LU_NAME specifies the variable for returning the 
fully qualified name of the LU at which the local transaction program 
is located. If the local fully qualified LU name is not known* a null 
value is returned. 

PARTNER_LU_NAME specifies the variable for returning the name of the 
LU at which the remote transaction program is located. This is a name 
by which the local LU knows the remote LU for the purpose of allocat¬ 
ing a conversation. Refer to the description of the LU_NAME parameter 
of ALLOCATE for more details. 

PARTNER_FULLY_QUALIFIED_LU_NAME specifies the variable for returning 
the fully qualified name of the LU at which the remote transaction 
program is located. If the partners fully qualified LU name is not 
known* a null value is returned. 

MODE_NAHE specifies the variable for returning the mode name for the 
session on which the conversation is allocated. 

SYNC_LEVEL specifies the variable for returning the level of synchros 
nidation processing being used for the conversation. The synchroni¬ 
zation levels are: 

• NONE 

• CONFIRM 
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• SYNCPT 

SECURITY_USER_ID specifies the variable for returning the user ID 
carried on the allocation request that initiated execution of the 
local program. A null value is returned if the allocation request did 
not contain a user ID. 

SECURXTY_PROFXLE specifies the variable for returning the profile 
carried on the allocation request that initiated execution of the 
local program. A null value is returned if the allocation request did 
not contain a profile. 

LUI4_IDENTIFIER specifies the variable for returning the logical unit 
of work (LUW) identifier associated with the conversation. The LUW 
identifier is created and maintained by the LU. The LU uses it to 
identify the most recent sync point and for accounting purposes, and 
for accounting purposes. If no LUW identifier is used on the conver¬ 
sation, a null value is returned. 

CONVERSATXON_CQRRELATOR specifies the variable for returning the con¬ 
versation correlator. The conversation correlator is created and 
maintained by the LU. The LU uses it during sync point resynchroniza- 
tion. If no conversation correlator is used on the conversation, a 
null value is returned. 

State Changes: 

None 

ABEND Conditions: 

Parameter Check 

• RESOURCE specifies an unassigned resource ID. 

• SECURITY_USER_ID is specified and not supported. 

• SECURITY_PROFILE is specified and not supported. 

• LUW_IDENTlFIER is specified and not supported. 

• CONVERSATION_CORRELATOR is specified and not supported. 

State Check 
None 
Notes: 

1. The program issues this verb in order to obtain the attributes of 
the conversation, including the one by which the program was 
started. 

2. Specifying SECURITY^USER_ID or SECURITY_PROFILE returns the user 
ID or profile carried on the allocation request that initiated 
execution of the local program, regardless of which resource ID is 
supplied on the RESOURCE parameter. 

3. The LU creates the LUW identifier for its use during sync point 
processing, and for accounting purposes. For sync point, the LUW 
identifier uniquely identifies the most recent synchronization 
point. 

4. The LU creates the conversation correlator for its use during sync 
point resynchronization. For sync point resynchronization, the 
conversation correlator correlates the logical unit of work to 
the sync point states associated with the current instance of the 
local program. 
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Causes the LU to post the specified conversation Mhen information is 
available for the program to receive* The information can be data# 
conversation status# or a request for confirmation or sync point. 
WAIT should be issued after P0ST_ON_RECEIPT in order to wait for post¬ 
ing to occur. Alternatively# TEST may be issued following 
P0ST_0N_RECEIPT in order to determine when posting has occurred. 



Supplied Parameters: 

POST_ON_RECEIPT 

resource ( variable ) 


[ FILL C LL ) 1 


[ ( BUFFER ) j 


LENGTH ( variable ) 


J 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

FILL specifies whether posting for data is to occur in terms of the 
logical-record format of the data. 

• LL specifies to post when a complete or truncated logical record 
is received# or when a part of a logical record is received that 
is at least equal in length to that specified on the LENGTH param¬ 
eter# whichever occurs first. 

• BUFFER specifies to post when data (independent of its 
logical-record format) is available that is at least equal in 
length to that specified by the LENGTH parameter# or when the end 
of data is available# whichever occurs first. 

The specification and effect of FILL(LL) versus FILL(BUFFER) is rele¬ 
vant only at the time the verb is issued. The specification does not 
depend on past use# and has no bearing on subsequent use# of this 
parameter on any verbs to which it applies (POST ON RECEIPT# 
RECEIVE_IMMEDIATE# and RECEIVE_AND_WAIT). 

Posting also occurs independent of the FILL specification when infor¬ 
mation other than data is received# such as conversation status (a 
SEND# PROG_ERROR_TRUNC, or DEALLOCATE_NORMAL indication# for exam¬ 
ple)# or a confirmation or sync-point request. 

LENGTH specifies the variable containing a length value# which is the 
maximum length of data that the program can receive. This parameter 
is used along with FILL to determine when to post the conversation for 
the receipt of data. 

State Changes? 

None 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

State Check 

The conversation is not in receive state. 
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Notes: 

1. This verb is intended to be used in conjunction with TEST or WAIT. 
The use of this verb and WAIT allows a program to perform synchro¬ 
nous receiving from multiple conversations* where the program 
issues this verb for each of the conversations and then issues 
MAIT (for each conversation) to wait until information is avail¬ 
able to be received on the conversations. The use of this verb 
and TEST allows a program to continue its processing and test the 
conversations to determine when information is available to be 
received. 

2. Posting occurs when the LU has any information that the program 
can receive* such as data* conversation status* or a request for 
confirmation or sync point. Refer to the RECEIVE_ANDJ»IAIT verb 
for a description of the types of information a program can 
receive. 

3. Posting is active for a conversation when POST_ON_RECEIPT has 
been issued for the conversation and posting has not yet been 
reset or cancelled. 

Posting is reset when any of the following verbs is issued for the 
same conversation as specified on POST_ON_RECEIPT after the con¬ 
versation is posted: 

BACKOUT 

DEALLOCATE with TYPE(ABEND.PROG), TYPECABEND SVC)* or 
TYPE(ABEND_TIMER) 

RECEIVE_AND_WAIT 

RECEIVE_IMMEDIATE 

SEND_ERROR 

TEST 

MAIT 

Posting is cancelled when any of the following verbs is issued for 
the same conversation as specified on P0ST_0H_RECEIPT before the 
conversation is posted: 

BACKOUT 

DEALLOCATE with TYPE(ABEHD.PROG)* TYPE(ABEND_SVC)* or 
TYPE(ABEND_TIMER) 

RECEIVE.IMMEDIATE 

SEND_ERROR 

In order for the program to activate posting again after posting 
has been reset or cancelled* the program issues another 
POST_ON_RECEIPT. 

4. Any number of POST_ONJRECEIPTs may be issued for a given conversa¬ 
tion before posting is reset or cancelled. The last 
POST_ON_RECEIPT issued for a conversation is the one that detei— 
mines when posting will occur for data. For example* if a program 
issues POST_ON_RECEIPT with FILLCBUFFER) and LEHGTH(IOOO) in 
preparation to receive 1000 bytes of data* and then issues the 
verb again with LENGTHC500)* posting will occur when 500 bytes of 
data are available* or if the program issues the verb again with 
FILL(LL)* posting will occur in terms of logical records. 

5. P0ST_0N_RECEIPT with LENGTHC0) has no special significance. It 
specifies that posting for data is to occur upon receipt of any 
amount of data of one byte or more. It is equivalent to 
P0ST_0N_RECEIPT with LENGTH(l)* 
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6, When FILL(BUFFER) is specified, posting for data occurs independ¬ 
ent of its logical record format. The conversation is posted when 
an amount of data is available that is equal to, or less than, the 
length specified on the LENGTH parameter. Posting for less data 
can occur only uihen the end of the data is available. The end of 
data occurs when it is followed by an indication of a change in 
the state of the conversation, that is, a change to send, confirm, 
sync-point, or deallocate state. See RECEIVE_AND_WAIT for addi¬ 
tional information. 

7. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Changes the conversation from send to receive state in preparation to 
receive data. The change to receive state can be either completed as 
part of this verb, or deferred until the program issues a FLUSH, CON¬ 
FIRM, or SYNCPT verb, hlhen it is completed as part of this verb it 
includes the function of the FLUSH or CONFIRM verb. 


Supplied Parameters; 


PREPARE_TO_RECEIVE 


RESOURCE ( variable ) 


1 ( SYNC LEVEL ) 
TYPE C FLUSH ) 

( CONFIRM ) 

[ LOCKS ( SHORT ) 1 
( LONG ) j 


Returned Parameters: 
RETURN_CODE ( variable ) 


; 


Supplied Parameters; 

RESOURCE specifies the variable containing the resource ID. 

TYPE specifies the type of prepare-to-receive to be performed for this 
conversation. 

• SYNC_LEVEL specifies to perform the prepare-to-receive based on 
the synchronization level allocated to this conversation: 

If SYNC_LEVEL(NONE), execute the function of the FLUSH verb 
and enter receive state. 

If SYNC_LEVEL(CONFIRM), execute the function of the CONFIRM 
verb and if it is successful (as indicated by a return code of 
OK on this PREPARE_TO_RECEIVE verb), enter receive state; if 
it is not successful,"the state of the conversation is deter¬ 
mined by the return code. 

— If SYNC_LEVEL(SYNCPT), enter defer state until the program 
issues a~$YNCPT, or the program issues a CONFIRM or FLUSH for 
this conversation. If the SYNCPT or CONFIRM is successful (as 
indicated by a return code of OK on that verb) or FLUSH is 
issued, receive state is then entered for this conversation; 
otherwise, the state of the conversation is determined by the 
return code. 

• FLUSH specifies to execute the function of the FLUSH verb and 
enter receive state. 

• CONFIRM specifies to execute the function of the CONFIRM verb and 
if it is successful (as indicated by a return code of OK on this 
PREPARE_TO_RECEIVE verb), enter receive state; if it is not suc¬ 
cessful, the state of the conversation is determined by the return 
code. 

The execution of the FLUSH or CONFIRM function as part of this verb 
includes the flushing of the LU's send buffer. Mhen, instead, defer 
state is entered, the LU defers flushing its send buffer until the 
program issues a subsequent verb for this conversation. 

LOCKS specifies when control i s to be returned to the local program 
following execution of the CONFIRM function of this verb or following 
execution of a CONFIRM verb issued subsequent to this verb. This 
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parameter is significant only when TYPE(CONFIRM) is also specified* 
or Mhen TYPE(SYNC_LEVEL) is also specified and the synchronization 
level for this conversation is CONFIRM; or when TYPE(SYNC_LEVEL) is 
also specified* the synchronization level for this conversation is 
SYNCPT* and a subsequent CONFIRM is issued* Otherwise* this parameter 
has no meaning and is ignored* 

• SHORT specifies to return control when an affirmative reply is 
received* as follows: 

— When the synchronization level is CONFIRM* return control 
from execution of this verb when a CONFIRMED reply is 
received* 

— When the synchronization level is SYNCPT* return control 

immediately from execution of this verb; return control from 
execution of a subsequent CONFIRM or SYNCPT verb when a corre¬ 
sponding CONFIRMED or SYNCPT reply is received* 

• LONG specifies to return control when information* such as data* 

is received from the remote program following an affirmative 

reply* as follows: 

— When the synchronization level is CONFIRM* return control 

from execution of this verb when information is received fol¬ 
lowing a CONFIRMED reply* 

— When the synchronization level is SYNCPT* return control 

immediately from execution of this verb; return control from 
execution of a subsequent CONFIRM or SYNCPT verb when infoi— 
mation is received following a corresponding CONFIRMED or 
SYNCPT reply. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. The TYPE parameter determines which of the following 
return codes can be returned to the program. 

• If TYPE(FLUSH) is specified, or if TYPE(SYNC_LEVEL> is specified 
and the synchronization level allocated to this conversation is 
NONE* the following return code is returned: 

- OK 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this conversation is CONFIRM, or TYPE(CONFIRM) is 
specified* one of the following return codes is returned: 

OK 

ALL0CATI0N_ERR0R 
DEALLOCATE_ABEND PROG 
DEALLOCATE_ABEND_SVC 
DEALLOCATE_ABEND_TIMER 
PRQG_ERROR_PURGING 
SVC_ERROR_PURGING 
RESOURCE FAILURE N0_RETRY 
RESQURCE_FAILURE_RETRY 

• If TYPE(SYNC_LEVEL) is specified and the synchronization level 
allocated to this conversation is SYNCPT* the following return 
code is returned: 

OK 

S_tate Changes (when RETURN CODE indicatesOK): 

Defer state is entered when TYPE(SYNC_LEVEL) is specified and the syn¬ 
chronization level is SYNCPT. 

Receive state is entered when TYPE(FLUSH) or TYPE(CONFIRM) is speci¬ 
fied* or when TYPE(SYNC_LEVEL) is specified and the synchronization 
level is NONE or CONFIRM* 
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• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

• TYPECCONFIRM) is specified and the conversation is allocated with 
SYNC_LEVELCNONE). 

• LOCKS(LONG) is specified and not supported. 

State Check 

• The conversation is not in send state. 

• The conversation is in send state, and the program started but did 
not finish sending a logical record. 

Notes: 

1. The TYPECSYNC_LEVEL) parameter is intended to be used by the 
transaction program in order to transfer send control to the 
remote program based on the synchronization level allocated to 
the conversation. 

• If the synchronization level is NONE, send control is trans¬ 
ferred to the remote program without any synchronizing 
acknowledgment• 

• If the synchronyzation level is CONFIRM, send control is 
transferred to the remote program with confirmation 
requested. 

• If the synchronization level is SYNCPT, transfer of send con¬ 
trol is deferred, klhen the local program subsequently issues 
SYNCPT, send control is transferred to the remote program 
with sync point requested. 

2. The TYPE(FLUSH) parameter is intended to be used by the trans¬ 
action program in order to transfer send control to the remote 
program without any synchronizing acknowledgment. TYPECFLUSH) is 
functionally equivalent to: 

• TYPECSYNC_LEVEL) with a synchronization level of NONE. 

• TYPECSYNClLEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the FLUSH verb. 

3. The TYPE(CONFIRM) parameter is intended to be used by the trans¬ 
action program in order to transfer send control to the remote 
program with confirmation requested. TYPE(CQNFIRM) is func¬ 
tionally equivalent to: 

• TYPECSYNClLEVEL) with a synchronization level of CONFIRM. 

• TYPECSYNClLEVEL) with a synchronization level of SYNCPT, fol¬ 

lowed by the CONFIRM verb. 

4. The remote transaction program receives send control by means of a 

what-received indication of SEND, CONFIRM^SEND, or 

TAKE_SYNCPT_SEND, as follows: 

• SEND: The local program specified either TYPE(FLUSH); 

TYPECSYNC_LEVEL) and the synchronization level is NONE; or 
TYPECSYNCJ.EVEL), the synchronization level is SYNCPT, and 
the local program subsequently issued FLUSH. 

• CONFIRM_SEND: The local program specified either 

TYPECCONFIRM); TYPECSYNCLLEVEL) and the synchronization level 
is CONFIRM; or TYPECSYNClLEVEL), the synchronization level is 
SYNCPT, and the local program subsequently issued CONFIRM. 

• TAKElSYNCPTlSEND: The local program specified 

TYPECSYNClLEVEL), the synchronization level is SYNCPT, and 
the local program subsequently issued SYNCPT. 
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5. If TYPE(SYNC_LEVEL) is specified and the synchronization level 
for the conversation is SYNCPT* the LU buffers the SEND notifica¬ 
tion to be sent to the remote program until the local program 
issues a verb that causes the LU to flush its send buffer. 

6. The conversation for the remote program enters the corresponding 
send state when.it issues a RECEIVE_ANDJdAIT or RECEIVE_IMMEDIATE 
verb and receives the SEND indication (on the WHAT_RECEIVED 
parameter.) The remote program can then send data to the local 
program. 

7. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Waits for information to arrive on the specified conversation and then 
receives the information. If information is already available* the 
program receives it without waiting. The information can be data# 
conversation status* or a request for confirmation or sync point. 
Control is returned to the program with an indication of the type of 
information. 

The program can issue this verb when the conversation is in send 
state. In this case* the LU flushes its send buffer* sending all buf¬ 
fered information and the SEND indication to the remote program. This 
changes the conversation to receive state. The LU then waits for 
information to arrive. The remote program can send data to the local 
program after it receives the SEND indication. 



Supplied Parameters: 

RECEXVE_AND_HAXT 

RESOURCE l variable ) 


f FILL C it 1 1 

[ ( BUFFER 1 J 


SuppI ied-and-Returned Parameters: 


LENGTH ( variable ) 


Returned Parameters: 

RETURN.CODE ( variable ) 

REQUEST_TO_SEND_RECEIVED C variable ) 

DATA ( variable ) 

UHAT.RECEXVED ( variable ) 


; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

FILL specifies whether the program is to receive data in terms of the 
logical-record format of the data. 

• LL specifies the program is to receive one complete or truncated 
logical record* or a portion of the logical record that is equal 
to the length specified by the LENGTH parameter. 

• BUFFER specifies the program is to receive data independent of its 
logical-record format. The amount of data received will be equal 
to* or less than* the length specified by the LENGTH parameter* 
The amount is less than the specified length when the program 
receives the end of the data. 

The specification and effect of FILL(LL) versus FILLCBUFFER) is rele¬ 
vant only at the time the verb is issued. The specification does not 
depend on past use* and has no bearing on subsequent use* of this 
parameter on any verbs to which it applies (P0ST_0N_RECEIPT* 
RECEIVE_AND_WAIT* and RECEIVE^IMMEDIATE). 

Supp lied-and-Returned Parameters: 

LENGTH specifies the variable containing a length value that is the 
maximum amount of data the program is to receive. When control is 
returned to the program this variable contains the actual amount of 
data the program received up to the maximum. If the program receives 
information other than data* this variable remains unchanged. 
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Returned Parameters; 

RETURN.CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of verb exe¬ 
cution. The return codes that can be returned depend on the state of 
the conversation at the time this verb is issued. 

• If this verb is issued in send state* the following return codes 
can be returned: 

- OK 

ALLOCATION ERROR 
BACKED_OUT 

DEALLOCATE_ABEND_PROG 

DEALLQCATE_ABEND_SVC 

DEALLOCATE_ABEND_TIMER 

PROG_ERROR_PURGING 

SVC_ERROR_PURGING 

RESOURCE_FAILURE_NO_RETRY 

RESOURCE_FAILURE_RETRY 

• If this verb is issued in receive state* the following return 
codes can be returned: 

OK 

ALL0CATI0N_ERR0R 
BACKED OUT 

DEALLOCATE_ABEND_PROG 

DEALLOCATE_ABEND_SVC 

DEALLQCATE_ABEND_TIMER 

DEALLOCATE^NORMAL 

PRQG_ERROR NO TRUNC 

PROG_ERRORlPURGING 

PROG_ERROR__TRUNC 

SVC_ERROR_NO_TRUNC 

SVC ERR0R — PURGING 

SVC~ERROR_TRUNC 

RESOURCE_FAILURE_NO_RETRY 

RESOURCE_FAILURE_RETRY 

R EQUEST_T 0_S END_R EC ElVED specifies the variable in which is returned 
an indication of whether REQUEST_TO_$END has been received. The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued REQUEST_TO_SEND* requesting the local program to enter 
receive state and thereby place the remote program in send state. 

• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

DATA specifies the variable in which the program is to receive the 
data. When the program receives information other than data* as indi¬ 
cated by the WHAT_RECEIVED parameter* nothing is placed in this vari¬ 
able. 

WHAT_RECEIVED specifies the variable in which is returned an indi¬ 
cation of what the transaction program received. The program should 
examine this variable only when RETURN_CODE indicates OK* otherwise* 
nothing is placed in this variable. 

• DATA is indicated when FILL(BUFFER) is specified and data (inde¬ 
pendent of its logical-record format) is received by the program. 

• DATA_COMPLETE is indicated when FILL(LL) is specified and a com¬ 
plete logical record* or the last remaining portion thereof* is 
received by the program. 

• DATA_INCOMPLETE is indicated when FILL(LL) is specified and less 
than a complete logical record is received by the program. The 
transaction program issues another RECEIVE_AND_WAIT (or possibly 
multiple RECEIVE_AND_WAITs) to receive the remainder of the data. 


4-78 


SNA Transaction Programmers Reference Manual for LU Type 6.2 



Basic Conversation Verbs 


• LL.TRUNCATED is indicated when FILL(LL) is specified and the 

2ybyte LL field of a logical record has been truncated after the 
first byte. The LU discards the truncated LL field; it is not 
received by the program. 

• SEND indicates the remote^ program has entered receive state* 
placing the local program in send state. The local program may 
now issue SEND_DATA. 

• CONFIRM indicates the remote program has issued CONFIRM* request¬ 
ing the local program to respond by issuing CONFIRMED. The pro¬ 

gram may respond* instead* by issuing a verb other than CONFIRMED* 
such as SEND_ERROR. 

• CONFIRM_SEND indicates the remote program has issued PRE- 

PARE_TO_RECEIVE with TYPE(CONFIRM); or with TYPE(SYNC_LEVEL), and 
either the synchronization level is CONFIRM, or it is SYNCPT and 
the remote program subsequently issued CONFIRM. The local pro¬ 
gram may respond by issuing CONFIRMED* or by issuing another verb 
such as SEND_ERROR. 

• CONFIRM_DEALLOCATE indicates the remote program has issued DEAL¬ 
LOCATE with TYPE(CONFIRM); or with TYPE(SYNC_LEVEL), and either 
the synchronization level is CONFIRM* or it is SYNCPT and the 
remote program subsequently issued CONFIRM. The local program 
may respond by issuing CONFIRMED* or by issuing another verb such 
as SEND_ERROR. 

• TAKE_SYNCPT indicates the remote program has issued SYNCPT, 
requesting the local program to respond by issuing SYNCPT in order 
to perform the sync-point function on all protected resources 
throughout the transaction. Issuing the SYNCPT verb also causes 
an affirmative reply to be returned to the remote program if the 
sync-point function is successful. The program may respond* 
instead* by issuing a verb other than SYNCPT* such as BACKOUT or 
SENDJERROR. 

• TAKE SYNCPT_SEND indicates the remote program has issued PRE- 
PARE_TO_RECEIVE with TYPE(SYNC_LEVEL)» the synchronization level 
is SYNCPT* and the remote program subsequently issued SYNCPT. The 
local program may respond by issuing SYNCPT* or by issuing another 
verb such as BACKOUT or SEND_ERROR. 

• TAKE_SYNCPT_DEALLOCATE indicates the remote program has issued 
DEALLOCATE with TYPE(SYNC_LEVEL)* the synchronization level is 
SYNCPT* and the remote program subsequently issued SYNCPT. The 
local program may respond by issuing SYNCPT* or by issuing another 
verb such as BACKOUT or SEND_ERROR. 

State Changes (when RETURN CODE indicates OK): 

Receive state is entered when the verb is issued in send state and 

WHAT_RECEIVED indicates DATA, DATA.COMPLETE, DATA_INCOMPLETE, or 

LL_TRUNCATED. 

Send state is entered when WHAT_RECEIVED indicates SEND. 

Confirm state is entered when WHAT_RECEIVED indicates CONFIRM* CON- 

FIRM_SEND, or CONFIRM_DEALLOCATE. 

sync-point state is entered when WHAT_RECEIVED indicates TAKE_SYNCPT* 

TAKE_SYNCPT_SEND, or TAKE_8YNCPT_DEALLOCATE. 

No state change occurs when the verb is issued in receive state and 

WHAT_RECEIVED indicates DATA, DATA_COMPLETE, DATA_INCOMPLETE, or 

LL_TRUNCATED. 

ABEND Conditions: 

Parameter Check 

RESOURCE specifies an unassigned resource ID. 
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State Check 

• The conversation is not in send or receive state. 

• The conversation is in send state* and the program started but did 
not finish sending a logical record. 

Notes: 

1. When the program issues RECEIVE_AND_WAIT in send state, the LU 
implicitly executes a PREPARE_TO_RECEIVE with TYPE(FLUSH) before 
executing the RECEIVE_AND_WAIT. Refer to the description of PRE- 
PARE_T(LRECEIVE for details of its function. 

2. When FILL(LL) is specified, the program is to receive a logical 
record and there are the following possibilities: 

• The program receives a complete logical record or the last 
remaining portion of a complete record. The length of the 
record or portion of the record is equal to or less than the 
length specified on the LENGTH parameter. The WHAT_RECEIVED 
parameter indicates DATA_COMPLETE. 

• The program receives an incomplete logical record. The log¬ 
ical record is incomplete because: 

— The length of the logical record is greater than the 
length specified on the LENGTH parameter; in this case 
the amount received equals the length specified. 

— Only a portion of the logical record is available because 
it has been truncated, the portion being equal to or less 
than the length specified on the LENGTH parameter. 

The WHAT_RECEIVED parameter indicates DATA_INCOMPLETE. The 
program issues another RECEIVE_AND_WAIT (or possibly multiple 
RECEIVE_AND_WAITs) to receive the" remainder of the logical 
record. 

• The program receives no part of the logical record because it 
was truncated after the first byte of the LL field. The 
WHAT_RECEIVED parameter indicates LL_TRUNCATED. 

Refer to the SEND_DATA verb for a definition of complete and 
incomplete logical records. 

3. When FILL(BUFFER) is specified* the program is to receive data 
independent of its logical-record format. The program receives 
an amount of data equal to, or less than, the length specified on 
the LENGTH parameter. The program can receive less data only when 
it receives the end of the data. The end of data occurs when it is 
followed by an indication of a change in the state of the conver¬ 
sation, that is, a change to send, confirm, sync-point, or deallo¬ 
cate state. The program is responsible for tracking the 
logical-record format of the data. 

4. RECEIVE_AND_WAIT with LENGTH(O) has no special significance. The 
type of information available is indicated by the RETURN_CODE and 
WHAT_RECEIVED parameters, as usual. If data is available and 
FILL(LL) is specified, the WHAT RECEIVED parameter indicates 
DATA_INCOMPLETE. If data is available and FILL(BUFFER) is speci¬ 
fied, the WHAT_RECEIVED parameter indicates DATA. In either 
case, however, the program receives no data. 

5. The program receives only one kind of information at a time. For 
example, it may receive data or a CONFIRM request, but it does not 
receive both at the same time. Also, if the remote program trun¬ 
cates a logical record, the local program receives the indication 
of the truncation on the RECEIVE_AND_WAIT it issues after receiv¬ 
ing all of the truncated record. The RETURN_CODE and 
WHAT_RECEIVED parameters indicate to the program the kind of 
information the program receives. 
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6. RECEIVE_AND_WAIT includes posting. If posting is already active 
when this verb is issued# this verb supersedes the prior 
P0ST_0N_RECEIPT function. Posting is reset at the completion of 
this verb. See the P0ST_0N_RECEIPT verb for more details about 
posting. 

7. The REQUEST_TQ_SEND notification is usually received when the 
local transaction program is in send state# and reported to the 
program on a SEND_DATA verb or on a SEND_ERROR verb issued in send 
state. However# the notification can be received when the program 
is in receive state under the following conditions: 

• When the local program just entered receive state and the 
remote program issued REQUEST^T0_SEND before it entered send 
state. 

• When the remote program has just entered receive state by 
means of the PREPARE_TO_RECEIVE verb (not RECEIVE_AND_WAIT)# 
and then issued REQUEST_TO_SEND before the local program 
enters send state. This can occur because the 
REQUEST_TO_SEND is transmitted as an expedited request and 
can therefore arrive ahead of the request carrying the SEND 
indication. Potentially# the local program cannot distin¬ 
guish this condition from the first. This ambiguity is 
avoided when the remote program waits until it receives 
information from the local program before it issues the 
REQUEST_TO_SEND. 

• When the remote program issues the REQUEST_TO_SEND in send 
state (see "Notes on Implementation Details 1 ' in Appendix A). 

8. The REQUEST_TO_SEND notification is returned to the program in 
addition to (not in place of) the information indicated by the 
RETURN_CODE and WHAT_RECEIVED parameters. 

9. References in this verb description to the program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Receives any information that is available from the specified conver¬ 
sation* but does not wait for information to arrive. The information 
(if any) can be data* conversation status* or a request for confirma¬ 
tion or sync point. Control is returned to the program with an indi¬ 
cation of whether any information was received and* if so* the type of 
information. 



Supplied Parameters: 

RECEXVE.XMMEDXATE 

resource ( variable ) 


f FILL C kk ) 1 


1 ( BUFFER ) 1 


Supplied-and-Returned Parameters: 


LENGTH ( variable 1 


Returned Parameters: 

RETURN.CODE ( variable ) 

REQUEST_TO_SEND_RECEXVED ( variable ) 

DATA ( variable 1 

UHAT_RECEXVED ( variable ) 


; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

FILL specifies whether the program is to receive data in terms of the 
logical-record format of the data. 

• LL specifies the program is to receive one logical record* or 
whatever portion of the logical record is available* up to the 
length specified by the LENGTH parameter. 

• BUFFER specifies the program is to receive data independent of its 
logical-record format* up to the length specified by the LENGTH 
parameter. 

The specification and effect of FILL(LL) versus FILL(BUFFER) is rele¬ 
vant only at the time the verb i s issued. The specification does not 
depend on past use* and has no bear-i-og. on subsequent use* of this 
parameter on any verbs to which it Applies (POST ON RECEIPT* 
RECEIVE_IMMEDIATE* and RECEIVE_AND_WAIT). 

Supplied-and-Returned Parameters: 

LENGTH specifies the variable containing a length value that is the 
maximum amount of data the program is to receive, kihen control is 
returned to the program this variable contains the actual amount of 
data the program received up to the maximum. If the program receives 
information other than data* or no information at all* this variable 
remains unchanged. 

Returned Parameters; 

RETURN.CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of verb exe¬ 
cution. 

• OK 

• ALLQCATION_ERRQR 
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• BACKED_OUT 

• DEALLOCATE ABEND PROG 

• DEALLOCATE~ABENDlSVC 

• DEALLQCATE_ABEND_TIMER 

• DEALLOCATE_NORMAL 

• PR0G_ERR0R NO TRUNC 

• PROG ERROR PURGING 

• PROG^ERRORlTRUNC 

• SVC_ERROR_NO_TRUNC 

• SVC_ERR0R_PURGING 

• SVC_ERROR_TRUNC 

• RESOURCE_FAILURE_NO_RETRY 

• RE50URCE_FAILURE_RETRY 

• UNSUCCESSFUL - There is nothing to receive. 

REQUEST_TO_SEND_RECEIVED specifies the variable in which is returned 
an indication of whether REQUEST__TO_SEND has been received. The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote program. The remote program has issued 
REQUEST_TO_SEND# requesting the local program to enter receive 
state and thereby place the remote program in send state. 

• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

DATA specifies the variable in which the program is to receive the 
data. When the program receives information other than data* as indi¬ 
cated by the WHAT_RECEIVED parameter# nothing is placed in this vari¬ 
able. 

MHAT_RECEIVED specifies the variable in which is returned an indi¬ 
cation of what the transaction program received. The program should 
examine this variable only when RETURN_CODE indicates OK; otherwise# 
nothing is placed in this variable. 

• DATA is indicated when FILL(BUFFER) is specified and data (inde¬ 
pendent of its logical-record format) is received by the program. 

• DATA_COMPLETE is indicated when FILL(LL) is specified and a com¬ 
plete logical record# or the last remaining portion thereof# is 
received by the program. 

• DATA_INCOMPLETE is indicated when FILL(LL) is specified and less 
than~a complete logical record is received by the program. The 
transaction program issues another RECEIVE_IMMEDIATE (or possibly 
multiple RECEIVE_IMMEDIATEs) to receive the remainder of the log¬ 
ical record. 

• LL_TRUNCATED is indicated when FILL(LL) is specified and the 
2-byte LL field of a logical record has been truncated after the 
first byte. The LU discards the truncated LL field; it is not 
received by the program. 

• SEND indicates the remote program has entered receive state# 
placing the local program in send state. The local program may 
now issue 5END_DATA. 

• CONFIRM indicates the remote program has issued CONFIRM# request¬ 
ing the local program to respond by issuing CONFIRMED. The pro¬ 
gram may respond# instead# by issuing a verb other than CONFIRMED# 
such as SEND_ERROR. 

• CONFIRM_SEND indicates the remote program has issued PRE- 
PARE_TO_RECEIVE with TYPE(CONFIRM); or with TYPE(SYNC_LEVEL), and 
either the synchronization level is CONFIRM# or it is SYNCPT and 
the remote program subsequently issued CONFIRM. The local pro¬ 
gram may respond by issuing CONFIRMED# or by issuing another verb 
such as SEND_ERROR. 

• CONFIRMJDEALLOCATE indicates the remote program has issued DEAL¬ 
LOCATE with TYPE(CONFIRM); or with TYPE(SYNC_LEVEL)# and either 
the synchronization level is CONFIRM# or it is SYNCPT and the 
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remote program subsequently issued CONFIRM. The local program 
may respond by issuing CONFIRMED* or by issuing another verb such 
as SEND_ERROR. 

• TAKE_SYNCPT indicates the remote program has issued SYNCPT* 
requesting the local program to respond by issuing SYNCPT in order 
to perform the sync-point function on all protected resources 
throughout the transaction. Issuing the SYNCPT verb also causes 
an affirmative reply to be returned to the remote program if the 
sync-point function is successful. The program may respond* 
instead* by issuing a verb other than SYNCPT* such as BACKGUT or 
SEND_ERROR. 

• TAKE SYNCPT_SEND indicates the remote program has issued PRE- 
PARElTO_RECEIVE with TYPE(SYNC_LEVEL)* the synchronization level 
is SYNCPT* and the remote program subsequently issued SYNCPT. The 
local program may respond by issuing SYNCPT* or by issuing another 
verb such as BACKOUT or SEND_ERROR. 

• TAKE_SYNCPT DEALLOCATE indicates the remote program has issued 
DEALLOCATE “with TYPE(SYNC_LEVEL), the synchronization level is 
SYNCPT* and the remote program subsequently issued SYNCPT. The 
local program may respond by issuing SYNCPT* or by issuing another 
verb such as BACKOUT or SEND_ERRQR. 

State Changes (when RETURN CODE indicates OK); 

Send state is entered when WHAT_RECEIVED indicates SEND. 

Confirm state is entered when WHAT RECEIVED indicates CONFIRM* CON- 

FIRM_SEND, or CONFIRM_DEALLOCATE. 

Sync-point state is entered when WHAT RECEIVED indicates TAKE_SYNCPT* 

TAKE_SYNCPT_SEND* or TAKE_SYNCPT_DEALLOCATE. 

No state change occurs when WHAT_RECEIVED indicates DATA* 

DATA_COMPLETE* DATA — INCOMPLETE* or LL_TRUNCATED. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• RESOURCE specifies an unassigned resource ID. 

state Check 

The conversation is not in receive state. 

Notes: 

1. When FILL(LL) is specified* the program is to receive a logical 
record and there are the following possibilities: 

• The program receives a complete logical record or the last 
remaining portion of a complete record. The length of the 
record or portion of the record is equal to or less than the 
length specified on the LENGTH parameter. The WHAT_RECEIVED 
parameter indicates DATA_COMPLETE. 

• The program receives an incomplete logical record. The log¬ 
ical record is incomplete because: 

— The length of the logical record is greater than the 
length specified on the LENGTH parameter; in this case 
the amount received equals the length specified. 

— Only a portion of the logical record is available (possi¬ 
bly because it has been truncated)* the portion being 
equal to or less than the length specified on the LENGTH 
parameter. 

The WHAT_RECEIVED parameter indicates DATA_INCOMPLETE. The 
program issues another RECEIVE_IMMEDIATE (or possibly multi- 
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pie RECEIVE.IMMEDIATEs) to receive the remainder of the log¬ 
ical record. 

• The program receives no part of the logical record because it 
Mas truncated after the first byte of the LL field. The 
WHAT.RECEIVED parameter indicates LL.TRUNCATED. 

Refer to the SEND.DATA verb for a definition of complete and 
incomplete logical records. 

2. When FILL(BUFFER) is specified* the program is to receive data 
independent of its logical-record format. The program receives 
whatever data is available* up to the amount specified on the 
LENGTH parameter. The program is responsible for tracking the 
logical-record format of the data. 

3. RECEIVE.IMMEDIATE with LENGTH(O) has no special significance. 
The type of information available* if any* is indicated by the 
RETURN.CODE and WHAT.RECEIVED parameters* as usual. If data is 
available and FILL(LL) is specified* the UIHAT RECEIVED parameter 
indicates DATA.INCOMPLETE. If data is available and FILL(BUFFER) 
is specified* the WHAT.RECEIVED parameter indicates DATA. In 
either case* however* the program receives no data. 

A. The program receives only one kind of information at a time. For 
example* it may receive data or a CONFIRM request* but it does not 
receive both at the same time. Also* if the remote program trun¬ 
cates a logical record* the local program receives the indication 
of the truncation on the RECEIVE.IMMEDIATE it issues after 
receiving all of the truncated record. The RETURN.CODE and 
WHAT.RECEIVED parameters indicate to the program the kind of 
information the program receives* if any. 

5. RECEIVE.IMMEDIATE resets or cancels posting. If posting is 
active and the conversation has been posted* posting is reset. If 
posting is active and the conversation has not been posted* post¬ 
ing is canceled (posting will not occur). See the POST.ON.RECEIPT 
verb for more details about posting. 

6. The REQUEST.TO.SEND notification is usually received when the 
local transaction program is in send state* and reported to the 
program on a SEND.DATA verb or on a SEND.ERROR verb issued in send 
state. However* the notification can be received when the program 
is in receive state under the following conditions: 

• When the local program just entered receive state and the 
remote program issued REQUEST.TO.SEND before it entered send 
state. 

• When the remote program has just entered receive state by 
means of the PREPARE.TO.RECEIVE verb (not RECEIVE.AND.WAIT), 
and then issued REQUEST.TO.SEND before the local program 
enters send state. This can occur because the 
REQUEST_TO_SEND is transmitted as an expedited request and 
can therefore arrive ahead of the request carrying the SEND 
indication. Potentially* the local program cannot distin¬ 
guish this case from the first. This ambiguity is avoided 
when the remote program waits until it receives information 
from the local program before it issues the REQUEST.TO.SEND. 

• When the remote program issues the REQUEST.TO.SEND in send 
state (see "Notes on Implementation Details" in Appendix A). 

7. The REQUEST.TO.SEND notification is returned to the program in 
addition to (not in place of) the information indicated by the 
RETURN.CODE and WHAT.RECEIVED parameters. 

8. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Notifies the remote program that the local program is requesting to 
enter send state for the conversation. The conversation will be 
changed to send state when the local program subsequently receives a 
SEND indication from the remote program. 



Supplied Parameters: 

REQUEST_TO_SEND 

RESOURCE ( variable ) 


* 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

State Changes: 

None 

abend Conditions; 

Parameter Check 

• RESOURCE specifies an unassigned resource ID. 

State Check 

• The conversation is not in receive* confirm* or sync-point state. 

Notes: 

1. The REQUEST_TO_SEND notification is indicated to the remote pro¬ 
gram by means of the REQUEST_TO_SEND_RECEIVED parameter. When 
the REQUEST_TO_SEND_RECEIVED parameter is set to YES* the remote 
program is requested to enter receive state and thereby place the 
local program in send state. A program enters receive state by 
means of the RECEIVE_AND_WAIT or PREPARE_TO_RECEIVE verb. The 
partner program enters the corresponding send state when it 
issues a RECEIVE_AND_WAIT or RECEIVE_IMMEDIATE verb and receives 
the SEND indication (on the MHAT_RECEIVED parameter). 

2. The REQUEST_TO_SEND_RECEIVED indication of YES is normally 
returned to the remote program when it is in send state* that is, 
on a SEND_DATA verb or on a SEND_ERROR verb issued in send state. 
However* it can be returned on a RECEIVE_AND_WAIT or 
RECEIVE — IMMEDIATE verb; see the description of RECEIVE_AND_WAIT 
or RECEIVE_IMMEDIATE for details about when this can occur. 

3. When the remote LU receives the REQUEST_TO_SEND notification* it 
retains the notification until the remote program issues a verb on 
which the notification can be indicated* that is* a verb with the 
REQUEST_TO_SEND_RECEIVED parameter. The remote LU will retain 
only one REQUEST__TO_SEND notification at a time (per conversa¬ 
tion); additional notifications are discarded until the retained 
notification is indicated to the remote program. It is therefore 
possible for the local program to issue the REQUEST_TO_SEND verb 
more times than are indicated to the remote program. 

4. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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SEND.DATA 


Sends data to the remote transaction program* The data format con¬ 
sists of logical records* The amount of data is specified independ¬ 
ently of the data format* 


SEND.DATA 

Supplied Parameters: 

RESOURCE ( variable ) 

DATA ( variable ) 

LENGTH C variable ) 


Returned Parameters: 


RETURN.CODE ( variable ) 


REQUEST_T0_SEND_RECEIVED ( variable ) 


• 

9 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID of the con¬ 
versation on which the data i s to be sent. 

DATA specifies the variable containing the data to be sent* The data 
consists of logical records. Each logical record consists of a 
two-byte length field (denoted as LL) followed by a data field; the 
length of the data field can range from zero to 32765 bytes. The 
two-byte length field contains the 15-bit binary length of the record, 
and a high-order bit that is not examined by the LU (it is used, for 
example, by the LU f s mapped conversation component in support of the 
mapped conversation verbs). The length of the record includes the 
two-byte length field, that is, it equals the length of the data field 
plus two. Thus, logical-record length values of hex 2 0000, 0001, 
8000, and 8001, are invalid. 

LENGTH specifies the variable containing the length of the data to be 
sent. This data length is not related in any way to the length of a 
logical record. It is used only to determine the length of the data 
located at the variable specified by the DATA parameter. 

The data length may be zero or greater. If zero, no data is sent for 
this issuance of the verb, and the DATA parameter is not significant. 
However, the other parameters are significant and retain their mean¬ 
ing as described. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the local program. The return code indicates the result of verb 
execution. 

• OK 

• ALL0CATI0N_ERR0R 

• PROG_ERROR_PURGING 

• SVC_ERROR_PURGING 

• DEALLOCATE_ABEND_PROG 

• DEALL0CATE_ABEND_SVC 

• DEALLOCATE_ABEND_TIMER 

• BACKED_OUT 

• RESOURCE_FAILURE_NO_RETRY 

• RESOURCE_FAILURE_RETRY 

REQUEST_T0_SEND_RECEIVED specifies the variable in which is returned 
an indication of whether REQUEST_TO_SEND has been received. The indi¬ 
cation is either YES or NO. 


Hex (meaning hexadecimal) refers to the base-16 numbering system. 
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• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued REQUE5T_T0_SEND, requesting the local program to enter 
receive state and thereby place the remote program in send state. 

• NO indicates a REQUEST^TO^SEND notification has not been 
received. 

State Changes (when RETURN COPE indicates OK): 

None 

ABEND Conditions: 

Parameter Check 

• RESOURCE specifies an unassigned resource ID. 

• DATA contains an invalid logical record length (LL) value of hex 
0000, 0001, 8000, or 8001. 

State Check 

The conversation is not in send state. 

Notes: 

1. The data sent by the program consists of logical records. The 
logical records are independent of the length of data as specified 
by the LENGTH parameter. That is, the data may consist of one or 
more complete records, the beginning of a record, the middle of a 
record, or the end of a record. The following combinations of 
these are also possible: 

• One or more complete records, followed by the beginning of a 
record. 

• The end of a record, followed by one or more complete records. 

• The end of a record, followed by one or more complete records, 
followed by the beginning of a record. 

• The end of a record, followed by the beginning of a record. 

2. The program must finish sending a logical record before issuing 
any of the following verbs: 

CONFIRM 

DEALLOCATE with TYPE(FLUSH), TYPECCONFIRM), or 
TYPE(SYNC_LEVEL) 

PREPARE_TO_RECEIVE 
RECEIVE_AND_WAIT 
SYNCPT 

A program finishes sending a logical record when it sends a com¬ 
plete record or when it truncates an incomplete record. 

3. A complete logical record contains the two-byte LL field and all 
bytes of the data field, as determined by the logical-record 
length. (If the data field is of zero length, the complete log¬ 
ical record contains only the two-byte length field.) An incom¬ 
plete logical record consists of any amount of data less than a 
complete record. It can consist of only the first byte of the LL 
field, the two-byte LL field plus all of the data field except the 
last byte, or any amount in between. A logical record is incom¬ 
plete until the last byte of the data field is sent, or until the 
second byte of the LL field is sent if the data field is of zero 
length. 

4. A program can truncate an incomplete logical record by issuing the 
SEND_ERROR verb. SEND_ERROR causes the LU to flush its send buff¬ 
er, which includes sending the truncated record. The LU then 
treats the first two bytes of data specified in the next SEND_DATA 
as the LL field. Issuing DEALLOCATE with TYPECABEND_PROG), 
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TYPE(ABEND_SVC)> or TYPE(ABEND_TIMER) also truncates an incom¬ 
plete logical record* 

5. The LU buffers the data to be sent to the remote LU until it accu¬ 
mulates from one or more SEND_DATAs a sufficient amount for trans- 
mi ssion* or until the local program issues a verb that causes the 
LU to flush its send buffer. The amount of data that is suffi¬ 
cient for transmission depends on the characteristics of the ses¬ 
sion allocated for the conversation* and can vary from one session 
to another. 

6. When REQUEST_TQ_SENDJ*ECEIVED indicates YES* the remote program 
is requesting the local program to enter receive state and thereby 
place the remote program in send state. A program enters receive 
state by means of the RECEIVE_AND_WAIT or PREPARE_TO_RECEIVE 
verb. The partner program enters the corresponding send state 
when it issues a RECEIVE_AND_WAIT or RECEIVE_IMMEDIATE verb and 
receives the SEND indication (on the WHAT_RECEIVED parameter). 

7. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Informs the remote transaction program that the local program 
detected an error. If the conversation is in send state* the LU 
flushes its send buffer. 

Upon successful completion of this verb* the local program is in send 
state and the remote program is in receive state. Further action is 
defined by transaction program logic. 



Supplied Parameters: 

SENDJERROR 

RESOURCE ( variable ) 


[ TYPE l PROG ) 1 
[ ( SVC ) J 


f LOG_DATA ( HO ) 1 

1 ( YES ( variable 1 ) J 


Returned Parameters: 

RETURN.CODE ( variable ) 

REQUEST_TO_SEND_RECEIVED ( variable ) 


; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

TYPE specifies the level of erroi-application or service—being 

reported. This parameter is intended to distinguish betuieen errors to 
be reported to end-user application transaction programs and errors 
to be reported to LU services transaction programs. 

• PROG specifies an end-user application program error is being 
reported. For instance* this error type is used by the LU serv¬ 
ices component for mapped conversation verbs in its processing of 
the MC_SEND_ERROR verb. The corresponding component at the 
remote LU Mill pass the error return code on to the remote 
end-user application program. 

• SVC specifies an LU services error is being reported. For 
instance* this error type is used by the LU services component for 
mapped conversation verbs to report errors detected Mi thin the LU 
services layer. 

I LOG_DATA specifies Nhether product-unique error information is to be 

placed in the system error logs of the LUs supporting this conversa¬ 
tion. 

• HO specifies that no error information is to be placed in the sys¬ 
tem error logs. 

• YES specifies that product-unique error information i s to be 
placed in the system error logs of the local and remote LUs. The 
specified variable contains the product-unique error information* 
in the format of the Error Log GDS variable. See SNA Format and 
Protocol Reference Manual; Architecture Logic for LU Type 6.2 for 
a definition of the Error Log GDS variable. 

Returned Parameters: 

RETURN_CODE specifies the variable in Mhich a return code is returned 
to the local program. The return code indicates the result of verb 
execution. The return codes that can be returned depend on the state 
of the conversation at the time this verb is issued: 
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• If the SEND_ERROR is issued in send state# the following return 
codes can be returned: 

OK 

ALLOCATION ERROR 

DEALLOCATE_ABEND PROG 

DEALLOCATE ABEND_SVC 

DEALLOCATE_ABEND_TIMER 

PROG_ERROR_PURGING 

SVC_ERROR_PURGING 

BACKED_OUT 

RESOURCE_FAILURE NO_RETRY 
RESOURCE^FAILURE_RETRY 

• If the SEND_ERROR is issued in receive state# the following return 
codes can be returned: 

OK 

DEALLOCATE_NORMAL 

RESOURCE_FAILURE_NO_RETRY 

RESOURCE_FAILURE_RETRY 

• If the SEND_ERROR is issued in confirm state or sync-point state# 
the following return codes can be returned: 

OK 

RESOURCE_FAILURE_NO_RETRY 

RESOURCE_FAILURE_RETRY 

REQUEST_TO_SEND_RECEIVED specifies the variable in which is returned 
an indication of whether REQUEST^T0_5END has been received. The indi¬ 
cation is either YES or NO. 

• YES indicates a REQUEST_TO_SEND notification has been received 
from the remote transaction program. The remote program has 
issued REQUEST_TO_SEND# requesting the local program to enter 
receive state and thereby place the remote program in send state. 

• NO indicates a REQUEST_TO_SEND notification has not been 
received. 

State Changes (when RETURN COPE indicates OK): 

Send state is entered when the verb is issued in receive# confirm# or 
sync-point state. 

No state change occurs when the verb is issued in send state. 

ABEND Conditions: 

Parameter Check 

• LOG^DATA is specified and not supported. 

• RESOURCE specifies an unassigned resource ID. 

State Check 

The conversation is not in send# receive# confirm# or sync-point 
state. 

Notes; 

1. The LU may send the error notification to the remote LU immediate¬ 
ly# that is# during the processing of this verb# or the LU may 
defer sending the notification until a later time. The determi¬ 
nation is made as follows: 

• If the local product does not support the FLUSH verb (see 
"Notes on Implementation Details" in Appendix A)# then the LU 
sends the error notification immediately. 

• If the local product does support the FLUSH verb# then the LU 
may or may not send the notification immediately# depending 
on the product. If the LU defers sending the notification# it 
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buffers the notification until it accumulates a sufficient 
amount of information for transmission* or until the local 
program issues a verb that causes the LU to flush its send 
buffer. The amount of information that is sufficient for 
transmission depends on the characteristics of the session 
allocated for the conversation, and can vary from one session 
to another. Transmission of the information may begin imme¬ 
diately* if the L0G_DATA parameter is specified with suffi¬ 
cient log data* or transmission may not begin until 
sufficient data from subsequent SEND_DATA verbs is also buf¬ 
fered. 

2. The local program can ensure that the remote program receives the 
error notification as soon as possible by issuing FLUSH imme¬ 
diately after SEND_ERROR. 

3. SEND_ERROR is reported to the remote transaction program as one of 
the following return codes (based on the TYPE parameter): 

• PROG_ERROR_TRUNC or SVC_ERROR_TRUNC - The local program 
issued SEND_ERROR in send state after sending an incomplete 
logical record (see SEND_DATA). The record has been trun¬ 
cated. 

• PR0G_ERR0R_N0_TRUNC or SVC_ERROR_NO_TRUNC - The local program 
issued SEND_ERROR in send state after sending a complete log¬ 
ical record (see SEND_DATA) or prior to sending any record. 
No truncation has occurred. 

• PROG_ERROR_PURGING or SVC_ERROR_PURGING - The local program 
issued SEND_ERROR in receive state and all information sent 
by the remote program and not yet received by the local pro¬ 
gram* if any* has been purged; or the local program issued 
SEND_ERROR in confirm or sync-point state* in which case no 
purging has occurred. 

4. When SEND_ERROR is issued in receive state* purging of incoming 
information occurs. The incoming information that is purged 
includes the following return code indications: 

• ALL0CATI0N_ERR0R 

• BACKED_OUT 

• DEALLOCATE_ABEND_PROG 

• DEALLOCATE_ABEND_SVC 

• DEALLOCATE_ABEND_TIMER 

• PR0G_ERR0R_N0_TRUNC 

• PROG ERROR_PURGING 

• PR0G_ERR0R TRUNC 

• SVC_ERROR_NO_TRUNC 

• SVC_ERROR_PURGING 

• SVC_ERROR_TRUNC 

The return code DEALLOCATE_NORMAL is reported instead of ALLO- 
CATI0N_ERR0R* DEALLOCATE_ABEND_PROG* DEALLOCATE_ABEND_SVC, or 
DEALLOCATE_ABEND_TIMER. The return code OK is reported instead 
of the other return codes. Mhen the return code BACKED_OUT is 
purged* the remote LU resends the BACKED_OUT indication and the 
local program receives the return code on a subsequent verb. 

The other kinds of incoming information that are purged are: 

• Data* sent by means of the SEND_DATA verb. 

• Confirmation request* sent by means of the CONFIRM, PRE- 
PARE_TO_RECEIVE, or DEALLOCATE verb. 

• Sync point request* sent by means of the SYNCPT* PRE- 
PARE_TO_RECEIVE, or DEALLOCATE verb. 

If the confirmation or sync point request was sent in conjunction 
with the DEALLOCATE verb (by means of its TYPE(CONFIRM) or 
TYPE(SYNC_LEVEL) parameter)* the deallocation request is also 
purged. 
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Incoming information that is not purged is the REQUEST_TO_SEND 
indication. This indication is reported to the program when it 
issues a verb that includes the REQUESTJTO_SEND_RECEIVED parame¬ 
ter. 

5. When REQUEST_TO_SEND_RECEIVED indicates YES, the remote program 
is requesting the local program to enter receive state and thereby 
place the remote program in send state. A program enters receive 
state by means of the RECEIVE_AND_WAIT or PREPARE_TO_RECEIVE 
verb. The partner program enters the corresponding send state 
when it issues a RECEIVE_ANDJ4AIT or RECEIVE.IMMEDIATE verb and 
receives the SEND indication Con the WHAT_RECEIVED parameter). 

6. The program may use this verb for various application-level func¬ 
tions. For example, the program may issue this verb to truncate 
an incomplete logical record it is sending, to inform the remote 
program of an error it detected in data it received, or to reject 
a confirmation or sync-point request. 

7. SEND_ERRQR resets or cancels posting. If posting is active and 
the conversation has been posted, posting is reset. If posting is 
active and the conversation has not been posted, posting is can¬ 
celed (posting will not occur). See the PQST_ON_RECEIPT verb for 
more details about posting. 

8. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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Tests the specified conversation for a condition. The return code 
indicates the result of the test. 



Supplied Parameters: 

TEST 

RESOURCE ( variable ) 


T TEST C POSTED 1 1 

[ ( REQUEST_TO_SEND_RECEIVED ) J 


Returned Parameters: 


RETURN.CODE ( variable ) 


; 


Supplied Parameters: 

RESOURCE specifies the variable containing the resource ID. 

TEST specifies the condition to be tested. 

• POSTED specifies to test whether the conversation has been 
posted. The return code indicates whether posting has occurred. 

• REQUEST_TD_SEND_RECEIVED specifies to test whether 
REQUEST_TO_SEND notification has been received from the remote 
transaction program. The return code indicates whether the 
notification has been received. 

Returned Parameters: 


RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of the test. 
The TEST parameter determines which of the following return codes can 
be returned to the program. 

• If TEST(POSTED) is specified, one of the following return codes is 
returned: 

OK 

— DATA 

— N0T_DATA 

POSTING_NOT_ACTIVE 

UNSUCCESSFUL 

ALLOCATION_ERROR 

BACKED_OUT 

- DEALLOCATE_ABEND_PROG 
DEALLOCATE_ABEND_SVC 
DEALLOCATE_ABEND_TIMER 
DEAL10CATE_N0RMAL 
PR0G_ERR0R N0_TRUNC 
PROG_ERROR_PURGING 
PROG_ERROR_TRUNC 
SVC_ERROR_NO_TRUNC 
SVC_ERR0R PURGING 
SVC_ERROR_TRUNC 
RESOURCE_FAILURE_NO_RETRY 
RESOURCE_FAILURE_RETRY 

• If TEST(REQUEST_TO_SEND_RECEIVED> is specified, one of the fol¬ 
lowing return codes is returned: 

OK 

UNSUCCESSFUL 
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State Changes (when RETURN CODE indicates OK): 

None 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• TESTCPOSTED) is specified and not supported. 

• TESTCREQUEST.TO.SEND.RECEIVED) is specified and not supported. 

• RESOURCE specifies an unassigned resource ID. 

State Check 

• TESTCPOSTED) is specified and the conversation is not in receive 
state. 

• TESTCREQUEST.TO.SEND.RECEIVED) is specified and the conversation 
is not in send, defer, or receive state. 

Notes: 

1. The TESTCPOSTED) parameter on this verb is intended to be used in 
conjunction with POST.ON.RECEIPT. The use of POST.ON.RECEIPT and 
this verb allows a program to continue its processing while wait¬ 
ing for information to become available, where the program issues 
P0ST_0N_RECEIPT for one or more conversations and then issues 
this verb for each conversation to determine when information is 
available to be received. 

2. For TESTCPOSTED), the return code indicates whether posting has 
occurred, as follows: 

• OK indicates posting was active for the conversation and it 
has been posted. Posting is now reset. The subcode of the OK 
return code indicates why the conversation has been posted. 

— DATA indicates data is available for the program to 
receive. 

- NOT DATA indicates information other than data, such as a 
SEND, CONFIRM, or TAKE.SYNCPT indication, is available 
for the program to receive. 

The program should issue RECEIVE.AND.WAIT or 
RECEIVE.IMMEDIATE in order to receive the information. The 
program may use the subcode to determine whether it needs to 
specify the DATA parameter on the RECEIVE.AND.WAIT or 
RECEIVE.IMMEDIATE verb. 

• POSTING_NOT_ACTIVE indicates posting is not active for the 
conversation. 

• UNSUCCESSFUL indicates posting is active for the conversation 
and it has not been posted. Posting remains active. 

The remaining return codes indicate posting was active for the 
conversation and it has been posted for the reason indicated by 
the specific return code. Posting is now reset. 

3. Posting is active for a conversation when POST.ON_RECEIPT has 
been issued for the conversation and posting has not been reset or 
canceled (see the P0ST_0N_RECEIPT verb). 

4. The TEST(REQUEST.TO.SEND.RECEIVED) parameter specifies to test 
whether REQUEST.TO.SEND notification has been received from the 
remote transaction program. The return code indicates whether 
the notification has been received, as follows: 

• OK indicates REQUEST.TO.SEND has been received. The remote 
program has issued REQUEST.TO.SEND, requesting the local pro¬ 
gram to enter receive state and thereby place the remote pro¬ 
gram in send state. A program enters receive state by means 


Chapter 4. Conversation Verbs 


4-95 


TEST 


of the* RECEIVE_AND_WAIT or PREPARE_TO_RECEIVE verb. The 
partner program enters the correspond!ng send state Mhen it 
issues a RECEIVE_ANDJ*JAIT or RECEIVE_IMMEDIATE verb and 
receives the SEND indication (on the WHAT RECEIVED parame¬ 
ter) . 

• UNSUCCESSFUL indicates REQUEST_TO_SEND has not been received. 

5. References in this verb description to a program being in a par¬ 
ticular state are only in terms of the specified conversation. 
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The verbs that a program may issue for a particular conversation 
depend on the state of the conversation. As the program issues verbs* 
the state of the conversation can change. The change in the state of 
the conversation is a result of the function of the verb* a result of 
a verb issued by the remote program* or a result of network errors. 

The state of a conversation is defined in terms of the local program's 
view of the local end of the conversation. The local end of the con¬ 
versation is the end to which the local program is connected. The 
states of other conversations allocated to the program can be differ¬ 
ent. For example* one conversation can be in receive state and anoth¬ 
er in send state* concurrently. The following conversation states are 
defined at the conversation protocol boundary (where the prefix CMC_] 
in a verb name means the verb can be either a mapped or basic conver¬ 
sation verb): 

Reset is the state in which the program can allocate the conversa¬ 
tion . 

Send is the state in which the program can send data* request con¬ 
firmation* or request sync point. 

Defer is the state* entered by the [MC_3PREPARE_T0_RECEIVE or 
CMC_]DEALLOCATE verb* in which the program can request sync point 
or confirmation* or simply flush the LU's send buffer* in order to 
complete the transition to receive or reset state. 

Receive is the state in which the program can receive information 
from the remote program. 

Confirm is the state in which the program can reply to a confirma¬ 
tion request. 

Sync point is the state in which the program can respond to a sync 
point request. 

Backed out is the state in which the program can respond to a 
backed out indication. 

Deallocate is the state in which the program can deallocate the 
conversation locally. 

The state of the conversation determines the verbs that a program is 
allowed to issue. Figure 4-1 on page 4-98 correlates the verbs# and 
parameters if applicable* to the conversation states. For each verb 
and state* a "yes*” "no*" or "n/a" is indicated* The "yes" means the 
program is allowed to issue the verb when the conversation is in that 
state. The "no" means the program cannot issue the verb when the con¬ 
versation is in that state because the verb is disallowed in that 
state. A verb issued for a conversation in a disallowed state is 
treated as a state-check ABEND condition (see "ABEND Conditions" in 
Chapter 3). The individual verb descriptions list the applicable 
state-check ABEND conditions. The "n/a" means the state is not appli¬ 
cable either because it cannot exist at the time the verb is issued or 
because it is not relevant to the verb. 

The SYNCPT and BACKOUT verbs apply to all protected resources at the 
time the verbs are issued* and only to protected resources. A conver¬ 
sation is protected when it is allocated with a synchroni zati on level 
of SYNCPT. Therefore* the correlation of the SYNCPT and BACKOUT verbs 
to conversation states applies only to protected conversations. The 
states of unprotected conversations — those allocated with a syn¬ 
chronization level other than SYNCPT — are not relevant to SYNCPT and 
BACKOUT. 
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Verb 

Conversation States 

Reset 

Send 

Defer 

Re¬ 

ceive 

Con- 
f i rm 

Sync 

point 

Backed 

out 

Deal¬ 

locate 

CMC_3ALL0CATE 

yes 

n/a 

n/a 

n/a 

n/a 

n/a 

n/a 

n/a 

CMC_3C0NFIRM 

n/a 

yes 

yes 

no 

no 

no 

no 

no 

tMC_3CONFIRMED 

n/a 

no 

no 

no 

yes 

no 

no 

no 

CMC_3DEALLOCATE with 

TYPECFLUSH), 
TYPECCONFIRM), or 

TYP E(SYN C_L EV EL) 

n/a 

yes 

no 

no 

no 

no 

no 

no 

CMC 3DEALL0CATE with 

TYPECABEND_PROG), 

TYPE(ABEND SVC), or 
TYPECABEND_TIMER) 

n/a 

yes 

yes 

yes 

yes 

yes 

no 

no 

CMC 3DEALL0CATE with 
TYPECLOCAL) 

n/a 

no 

no 

no 

no 

no 

no 

yes 

CMC_3FLUSH 

n/a 

yes 

yes 

no 

no 

no 

no 

no 

CMC_3GET_ATTRIBUTES 

n/a 

yes 

yes 

yes 

yes 

yes 

yes 

yes 

CMC_3P0ST_0N_RECEIPT 

n/a 

no 

no 

yes 

no 

no 

no 

no 

CMC_3PREPARE_T0_RECEIVE 

n/a 

yes 

no 

no 

no 

no 

no 

no 

CMC_3RECEIVE_AND_WAIT 

n/a 

yes 

no 

yes 

no 

no 

no 

no 

EMC_3RECEIVE_IMMEDIATE 

n/a 

no 

no 

yes 

no 

no 

no 

no 

CMC_3REQUEST_T0_SEND 

n/a 

no 

no I 

yes 

yes 

yes 

no 

no 

[MC_3SEND_DATA 

n/a 

yes 

no 

no 

no 

no 

no 

no 

CMC_3SEND_ERR0R 

n/a 

yes 

no 

yes 

yes 

yes 

no 

no 

tMC_]TEST with 
TESTCPOSTED) 

n/a 

no 

i 

no 

yes 

no 

no 

no 

no 

CMC_3TEST with 

TEST<REQUEST_TO SEND 
RECEIVED) 

n/a 

yes 

yes 

yes 

no 

no 

no 

no 

BACKOUT 

n/a 

yes 

yes 

yes 

yes 

yes 

yes 

n/a 

GET_TYPE 

n/a 

yes 

yes 

yes 

yes 

yes 

yes 

yes 

SYNCPT 

n/a 

yes 

yes 

no 

no 

yes 

no 

n/a 

WAIT 

n/a 

no 

no 

yes 

no 

no 

no 

no 


Figure 4-1. Correlation of Conversation Verbs to the Conversation States Allowing 
Thei r Issuance 


A conversation enters a particular state when the program issues a 
verb that causes a state transition or when the program receives a 
return code that indicates a state transition. the specific state 
transitions are defined in the individual verb descriptions under the 
heading "State Changes," and in the return code descriptions under 
"Return Codes" on page 4-99. 
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Some verbs have a parameter called RETURN_CODE used to pass a return 
code back to the program at the completion of the LU's execution of a 
verb. The return code indicates the result of verb execution* includ¬ 
ing any state changes to the specified conversation. See "Conversa¬ 
tion States" on page 4-97 for a definition of the states. 

Some of the return codes indicate results of the local LU's processing 
of a verb? these return codes are returned on the verb that invoked 
the local processing. Other return codes indicate results of process¬ 
ing invoked at the remote end of the conversation and* depending on 
the verb* can be returned on the verb that invoked the remote process¬ 
ing or on a subsequent verb. Still other return codes report events 
that originate at the remote end of the conversation. In any case* 
only one code is returned at a time. Other verb-specific information 
may be passed back in verb-unique parameters. See each specific verb 
for a description of any verb-unique parameters. 

Some of the return codes have the suffix "RETRY" or "N0_RETRY" in 
their name. RETRY means that the condition indicated by the return 
code may not be permanent* and the program may attempt to allocate the 
conversation again. Whether the retry attempt succeeds depends on the 
duration of the condition. In general* the program should limit the 
number of times it attempts to retry without success* after which it 
should consider the condition permanent. N0_RETRY means that the con¬ 
dition is most likely permanent* and* in general* no attempt should be 
made to allocate the conversation again until the condition is cor¬ 
rected. 

The return codes are described below. Each description includes the 
meaning of the return code* the origin of the condition indicated by 
the return code* when the return code can be reported to the program* 
and the state of the conversation when control is returned to the pro¬ 
gram. The individual verb descriptions list the applicable return 
codes. 

ALLOCATXON_ERROR indicates the local program issued an 
MC_ALLOCATE or ALLOCATE verb and allocation of the specified con¬ 
versation could not be completed. The ALLQCATION_ERRQR indi¬ 
cation together with one of the following subcodes form the 
complete return code that is returned to the program* the subcode 
identifies the specific error. (The remote LU and remote program 
referred to in the following subcode definitions are the LU named 
on the LU_NAME parameter and the program named on the TPN parame¬ 
ter* respectively* of the verb.) When ALLOCATIQN_ERROR (with any 
subcode) is returned to the program* the conversation is in deal¬ 
locate state. 

♦ ALLOCATION_FAILURE_NO_RETRY indicates the conversation can¬ 
not be allocated on a session because of a condition that is 
not temporary. For example* the session to be used for the 
conversation cannot be activated because the current 
(LU*mode) session limit for the specified (LU-name*mode-name) 
pair is 0* or because of a system definition error or a 
session-activation protocol error* or the session was deacti¬ 
vated because of a session protocol error before the conver¬ 
sation could be allocated. The program should not retry the 
allocation request until the condition is corrected. This 
return code is returned on the MC^ALLOCATE or ALLOCATE verb 
when the program specifies (by means of the RETURN_C0NTR0L 
parameter) that the local LU i s to attempt to allocate a ses¬ 
sion before returning control to the program; otherwise* it 
is returned on a subsequent verb. 

• ALLOCATXON_FAILURE_RETRY indicates the conversation cannot be 
allocated on a session because of a condition that may be tem¬ 
porary. For example* the session to be used for the conversa¬ 
tion cannot be activated because of a temporary lack of 
resources at the local LU or remote LU* or the session was 
deactivated because of session outage before the conversation 
could be allocated. The condition may be temporary* and the 
program can retry the allocation request. This return code is 
returned on the MC_ALLOCATE or ALLOCATE verb when the program 
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specifies (by means of the RETURN_C0NTR0L parameter) that the 
local LU is to attempt to allocate a session before returning 
control to the program; otherwise# it is returned on a subse¬ 
quent verb. 

• CONVERSATION_TYPE_MISMATCH indicates the remote LU rejected 
the allbcation request because the local program issued an 
MC_ALLOCATE or ALLOCATE verb and the remote program does not 
support the respective mapped- or basic-conversation protocol 
boundary# or the local program issued an MC_ALLOCATE verb and 
the remote LU does not support mapped conversations. This 
return code is returned on a subsequent verb. 

• PIP_NOT_ALLOWED indicates the remote LU rejected the allo¬ 
cation request because the local program specified program 
initialization parameters (by means of the PIP(YES) parame¬ 
ter) and either the remote LU does not support PIP data# or 
the remote program has no PIP variables defined (see "Trans¬ 
action Program Structure and Execution" in Chapter 3). This 
return code is returned on a subsequent verb. 

• PIP_NOT_SPECIFIED_CORRECTLY indicates the remote LU rejected 
the allocation request because the remote program has one or 
more PIP variables defined and the local program specified no 
program initialization parameters (by means of the PIP(NO) 
parameter)# or it specified program initialization parameters 
(by means of the PIP(YES) parameter) that do not correspond in 
number to those defined for the remote program. This return 
code is returned on a subsequent verb. 

• SECURITY_NOT_VALID indicates the remote LU rejected the allo¬ 
cation request because the access security information (spec¬ 
ified by means of the SECURITY parameter) is invalid. This 
return code is returned on a subsequent verb. 

• SYNC_LEVEL_NQT_SUPPORTED_BYJLU indicates the local LU 

rejected the allocation request because the local program 
specified a synchronization level (by means of the SYNC_LEVEL 
parameter) that the remote LU does not support. This return 
code is returned on the MC_ALLQCATE or ALLOCATE verb when the 
program specifies (by means of the RETURN_C0NTR0L parameter) 
that the local LU is to attempt to allocate a session before 
returning control to the program# otherwise# it is returned 
on a subsequent verb. 

• SYNCJLEVEL_NOT_SUPPQRTED_BY_PGM indicates the remote LU 

rejected the allocation request because the local program 
specified a synchronization level (by means of the $YNC_LEVEL 
parameter) that the remote program does not support. This 
return code is returned on a subsequent verb. 

• TPN_NOT_RECOGNIZED indicates the remote LU rejected the allo¬ 
cation request because the local program specified a remote 
program name that the remote LU does not recognize. This 
return code is returned on a subsequent verb. 

• TRANS_PGM_NOT_AVAIL_NO_RETRY indicates the remote LU rejected 

the allocation request because the local program specified a 
remote program that the remote LU recognizes but cannot 
start. The condition is not temporary# and the program should 
not retry the allocation request. This return code is 

returned on a subsequent verb. 

• TRANSJ>GM_NOT_AVAIL_RETRY indicates the remote LU rejected 

the allocation request because the local program specified a 
remote program that the remote LU recognizes but currently 
cannot start. The condition may be temporary# and the program 
can retry the allocation request. This return code is 

returned on a subsequent verb. 

With one exception# the subcodes of ALL0CATI0N_ERR0R are not 

explicitly listed in the individual verb descriptions# as any of 

them can be returned as part of the ALLOCATIONJERRGR return code. 

The exception to this is for the MC_ALLOCATE and ALLOCATE verbs# 
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on which only certain subcodes can be returned; therefore, the 
applicable subcodes are listed for these verbs. 

BACKED_OUT indicates the remote program issued a BACKOUT, or the 
local or remote LU has done so, in order to restore all protected 
resources to their status as of the lash synchronization point. 
This return code can be reported to the local program on a verb it 
issues in send, defer, or receive state. The conversation is in 
backed-out state. 

DEALLOCATE_ABEND indicates the remote program issued an 
MC_DEALLOCATE verb specifying the TYPECABEND) parameter, or the 
remote LU has done so because of a remote program ABEND condition. 
If the conversation for the remote program was in receive state 
when the verb was issued, information sent by the local program 
and not yet received by the remote program is purged. This return 
code can be reported to the local program on a verb it issues in 
send, defer, or receive state. The conversation is in deallocate 
state. 

DEALLOCATE_ABEND_PRQG indicates the remote program issued a DEAL¬ 
LOCATE verb specifying the TYPECABEND_PROG) parameter, or the 
remote LU has done so because of a remote program ABEND condition. 
If the conversation for the remote program was in receive state 
when the verb was issued, information sent by the local program 
and not yet received by the remote program is purged. This return 
code can be reported to the local program on a verb it issues in 
send, defer, or receive state. The conversation is in deallocate 
state. 

DEALLOCATE_ABEND_SVC indicates the remote program issued a DEAL¬ 
LOCATE verb specifying the TYPECABEND_SVC) parameter. If the 
conversation for the remote program was in receive state when the 
verb was issued, information sent by the local program and not yet 
received by the remote program is purged. This return code can be 
reported to the local program on a verb it issues in send, defer, 
or receive state. The conversation is in deallocate state. 

DEALLOCATE_ABEND TIMER indicates the remote program issued a 
DEALLOCATE verb specifying the TYPECABEND.TIMER) parameter. If 
the conversation for the remote program was in receive state when 
the verb was issued, information sent by the local program and not 
yet received by the remote program is purged. This return code 
can be reported to the local program on a verb it issues in send, 
defer, or receive state. The conversation is in deallocate state. 

DEALLOCATE.NORMAL indicates the remote program issued an 
MC_DEALLOCATE or DEALLOCATE verb specifying the TYPECSYNCJ.EVEL) 
or TYPECFLUSH) parameter; if TYPE(SYNC_LEVEL), either the syn¬ 
chronization level is NONE or it is SYNCPT and the remote program 
subsequently issued an MC_FLUSH or FLUSH verb. This return code 
is reported to the local program on a verb it issues in receive 
state. The conversation is in deallocate state. 

FMH_DATA_NOT_SUPPORTED indicates the local program issued an 
MC_SEND_DATA specifying that the data record contains FM headers 
Cby means of the FMH_DATA parameter), and either the remote LU or 
remote program does not support FM header data. This return code 
is reported on a subsequent verb. All information sent by the 
local program on the MC_SEND_DATA verb and subsequent verbs prior 
to the reporting of the FMH_DATA_NOT_SUPPORTED return code is 
purged. The conversation is in send state. 

HEURISTXC_MXXED indicates the local program issued a SYNCPT and 
an error occurred during the sync point processing within the dis¬ 
tributed transaction. As a result of the error and subsequent LU 
operator intervention, at least one LU advanced its local pro¬ 
tected resources to the next synchronization point and at least 
one LU restored its local protected resources to the previous syn¬ 
chronization point. 

MAP_EXECUTXON_FAXLURE indicates the local program issued an 
MC_5END_DATA specifying the data record is to be mapped (by means 
of the MAP_NAME parameter), and the local LU or the remote LU 
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could not map the data record based on the map name. This return 
code is returned on the MC_SEND_DATA verb when the map execution 
failed at the local LU. ’"Otherwise, the remote LU rejects the 
data, and the return code is reported on a subsequent verb. All 
information sent by the local program on that MC_$END_DATA verb 
and subsequent verbs prior to the reporting of the 
MAP_EXECUTION_FAILURE return code is purged. The conversation is 
in send state. 

MAP_NOT_FOUND indicates the local program issued an MC_.SEND_.DATA 
specifying the data record is to be mapped (by means of the 
MAP_NAME parameter), and the map name is unknown to the local LU 
or the remote LU. This return code is reported on the 
MC_SEND_DATA verb when the map name is unknown to the local LU. 
Otherwise, the remote LU rejects the data, and the return code is 
reported on a subsequent verb. All information sent by the local 
program on that MC_$END_DATA verb and subsequent verbs prior to 
the reporting of the MAP_NOT_FOUND return code is purged. The 
conversation is in send state. 

MAPPING_NOT_SUPPORTED indicates the local program issued an 
MC_SEND_DATA specifying the data record i s to be mapped (by means 
of the MAP_NAME parameter), and either the remote LU or remote 
program does not support data mapping. This return code is 
reported on a subsequent verb. All information sent by the local 
program on that MC_SEND_DATA verb and subsequent verbs prior to 
the reporting of the MAPPING_NOT_SUPPQRTED return code is purged* 
The conversation is in send state. 

OK indicates the verb issued by the local program executed sue* 
cessfully. That is, the function defined for the verb, up to the 
point at which control is returned to the program, was performed 
as specified. The state of the conversation is as defined for the 
verb. 

For some verbs, the OK indication together with one of the follow¬ 
ing subcodes form the complete return code that is returned to the 
program; the subcode provides additional information. 

• DATA indicates data is available for the program to receive. 

• NOT_DATA indicates information other than data is available 
for the program to receive. 

PARAMETER_ERROR indicates the local program issued a verb speci¬ 
fying a parameter containing an invalid argument. The source of 
the argument is considered to be outside the program definition, 
such as an LU name supplied by a terminal operator and used as the 
argument of LU_NAME on MC_ALLOCATE or ALLOCATE. Contrast this 
definition with the definition of the ABEND condition. Parameter 
Check, in the section "ABEND Conditions" in Chapter 3. This 
return code is returned on the verb specifying the invalid argu¬ 
ment. The state of the conversation remains unchanged. 

POSTING_NOT_ACTIVE indicates the local program issued a verb that 
determines whether a resource has been posted, and posting is not 
active for any of the specified resources. 

PROG_ERRORJ*OJTRUNC indicates one of the following: 

• The remote program issued an MC_$END_ERROR verb and the con¬ 
versation for the remote program was in send state. No trun¬ 
cation occurs at the mapped conversation protocol boundary. 
This return code is reported to the local program on an 
MC_RECEIVE_AND_WAIT or MC_RECEIVE_IMMEDIATE verb it issues 
prior to receiving any data records or after receiving one or 
more data records. 

• The remote program issued a SEND m ERROR verb specifying the 
TYPE(PROG) parameter, the conversation for the remote program 
was in send state, and the verb did not truncate a logical 
record. No truncation occurs at the basic conversation pro¬ 
tocol boundary when a program issues SENDMERROR before send¬ 
ing any logical records or after sending a complete logical 
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record. This return code is reported to the local program on 
a RECEIVE_AND_WAIT or RECEIVEJWMEDIATE verb it issues prior 
to receiving any logical records or after receiving one or 
more complete logical records. 

The conversation remains in receive state, 

PROG_ERROR__PURGXNG indicates the remote program issued an 
MC_SEND_ERROR verb or it issued a SEND_ERROR verb specifying the 
TYPE(PROG) parameter, and the conversation for the remote program 
Mas in receive, confirm, or sync point state. The verb may have 
caused information to be purged. Purging occurs uhen a program 
issues MC_SEND_ERROR or SEND_ERROR in receive state before 
receiving all the information sent by its partner program, that 
is, all the information sent prior to the reporting of the 
PROG_ERROR_PURGING return code to the partner program. The purg¬ 
ing can occur at the local LU, remote LU, or both. No purging 
occurs Mhen a program issues the verb in confirm state or sync 
point state, or in receive state after receiving all the informa¬ 
tion sent by its partner program. This return code is normally 
reported to the local program on a verb it issues after sending 
some information to the remote program. HoMever, the return code 
can be reported on a verb the program issues prior to sending any 
information, depending on the verb and Mhen it is issued. The 
conversation is in receive state. 

PROG_ERROR_TRUNC indicates the remote program issued a SEND_ERROR 
verb specifying the TYPE(PROG) parameter, the conversation for 
the remote program Mas in send state, and the verb truncated a 
logical record. Truncation occurs at the basic conversation pro¬ 
tocol boundary Mhen a program begins sending a logical record and 
then issues SEND_ERROR before sending the complete logical 
record. This return code is reported to the local program on a 
RECEIVE_AND_WAIT or RECEIVE^IMMEDIATE verb it issues after 
receiving the truncated logical record. The conversation remains 
in receive state. 

SVC_ERROR_NO_TRUHC indicates the remote program issued a 
SEND_ERROR verb specifying the TYPE(SVC) parameter. OtherMise, 
this return code, as it applies to the basic conversation protocol 
boundary, has the same meaning as PROG_ERROR_NO_TRUNC. The con¬ 
versation remains in receive state. 

SVC_ERROR_PURGING indicates the remote program issued a 
SEND_ERROR verb specifying the TYPE(SVC) parameter. OtherMise, 
this return code, as it applies to the basic conversation protocol 
boundary, has the same meaning as PRGG_ERROR_PURGING. The con¬ 
versation is in receive state. 

SVC_ERROR_TRUNC indicates the remote program issued a SEND_ERROR 
specifying the TYPE(SVC) parameter. OtherMise, this return code 
has the same meaning as PROG_ERROR_TRUNC. The conversation 
remains in receive state. 

RESOURCE_FAILURE_NO_RETRY indicates a failure occurred that 
caused the conversation to be prematurely terminated. For exam¬ 
ple, the session being used for the conversation Mas deactivated 
because of a session protocol error, or the conversation Mas deal¬ 
located because of a protocol error between the mapped conversa¬ 
tion components of the LUs. The condition is not temporary, and 
the program should not retry the transaction until the condition 
is corrected. This return code can be reported to the local pro¬ 
gram on a verb it issues in any state other than reset or deallo¬ 
cate. The conversation is in deallocate state. 

RESOURCE_FAILURE_RETRY indicates a failure occurred that caused 
the conversation to be prematurely terminated. For example, the 
session being used for the conversation was deactivated because 
of a session outage, such as a line failure, a modem failure, or a 
crypto engine failure. The condition may be temporary, and the 
program can retry the transaction. This return code can be 
reported to the local program on a verb it issues in any state 
other than reset or deallocate. The conversation is in deallocate 
state. 
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UNSUCCESSFUL indicates the verb issued by the local program did 
not execute successfully* This return code is returned on the 
unsuccessful verb* The state of the conversation remains 
unchanged* 

Figure 4-2 on page 4-105 shows the correlation of the return codes to 
the verbs on which they can be returned. The "X" in the figure means 
the return code can be returned on the corresponding verb. A verb 
without any w X w s beside it means no return codes are defined for the 
verb. 
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CHAPTER 5. CONTROL-OPERATOR VERBS 


This chapter describes the category of verbs called control-operator 
verbs . The control-operator verbs define the protocol boundary for a 
control-operator transaction program. In particular, the control- 
operator protocol boundary is intended for use by transaction pro¬ 
grams that assist the control operator in performing functions 
related to the control of an LU. 

Preceding the detailed descriptions of the control-operator verbs is 
a discussion of LU-LU sessions and functional subcategories of the 
control-operator verbs. Following the verb descriptions is a 
description of the return codes that apply to the control-operator 
verbs. 


LU-LU SESSIONS 


The following characteristics of LU-LU sessions are relevant to the 
control-operator verbs: 

• The means of connecting LUs — single session or parallel sessions 

• The contention-winner polarities of LU-LU sessions 


SINGLE AND PARALLEL SESSIONS 

Two LUs may connect to each other by means of one LU-LU session, 
called a single session # or multiple LU-LU sessions, called parallel 
sessions . The means of connection, single session or parallel ses¬ 
sions, depends on the products implementing the LUs. LU 6.2 products 
that provide an application programming interface (API), for 
user-written programs, equivalent to the conversation verbs support 
both single-session and parallel-session connections. Products that 
are not user programmable, or that are but do not provide an API 
equivalent to the conversation verbs, may support only single-session 
connections, and typically do so; however, they may also support par¬ 
allel-session connections. 

• When parallel-session support is available to both LUs, they can 
connect to each other using a single session or parallel sessions. 

• When parallel-session support is unavailable to either LU, they 
can connect to each other using only a single session. 

The session activation request that one LU sends to another indicates 
whether the session is a single session or a parallel session. 

An LU for which parallel session support is available establishes the 
means of connection to a partner LU at the time the partner LU is 
defined (see the DEFINE m REMOTE_LU verb). Two LUs cannot be connected 
by both single and parallel sessions at the same time. 

For single-session connections, an implied limit of 1 is imposed on 
the number of active sessions between the two LUs. That is, another 
session cannot be activated until the active session is deactivated. 

For parallel-session connections, the sessions can be partitioned 
into groups. Each group has a limit on the number of active sessions 
within that group, which is agreed to by both LUs. Additional ses¬ 
sions within a group can be activated up to its limit. 

Each single session or group of parallel sessions has associated with 
it a set of similar network properties and a corresponding mode name. 
The mode name serves as an identifier of the set of network proper¬ 
ties. It allows a transaction program to select the set of network 
properties to be used for a conversation. 
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The set of similar network properties includes* for example* the high¬ 
est synchronization level for conversations on the sessions* the 
class of service for the sessions* whether the sessions provide trans¬ 
mission security by means of session- or link-level cryptography* and 
the session routing and delay characteristics. The correlation of 
mode names to the sets of network properties is established at the 
time the mode name is defined for the partner LU (see the DEFINE_MODE 
verb). 

The similarity of network properties among a group of sessions does 
not imply that the network properties must be identical for all ses¬ 
sions in the group. For example* the sessions within a group can be 
activated on different physical transmission facilities and yet have 
equivalent class of service* or they can have different physical secu¬ 
rity characteristics and still have equivalent level of transmission 
security. 


CONTENTION-WINNER POLARITY 

For each single or parallel LU-LU session* only one LU is the con¬ 
tention winner of the session* the other LU is the contention loser of 
the session. This contention-winner polarity of LU-LU sessions 
determines how contention is resolved when the two LUs attempt to 
allocate a conversation on the session at the same time. 1 The conten¬ 
tion-winner LU allocates a conversation on a session without asking 
permission from the contention-loser LU. Conversely* the conten¬ 
tion-loser LU requests permission from the contention-winner LU to 
allocate a conversation on the session* and the contention-winner LU 
either grants or rejects the request. The contention-winner polarity 
of a session is established at session activation time. 

For single sessions* the LU initiating the session activation can 
request that it be the contention winner or loser. The LU responding 
to the session activation can accept the requested polarity or change 
the polarity* depending on the requested polarity. If the initiating 
LU requests that it be the contention winner* the responding LU can 
accept the polarity or change the polarity making it the contention 
winner. If the initiating LU requests that it be the contention 
loser* the responding LU always accepts the polarity. 

For parallel sessions* each mode-name group of sessions can be parti¬ 
tioned based on contention-winner polarities. A number of sessions in 
the group can be designated as the minimum number of contention-winner 
sessions for one LU* and all or part of the remaining sessions can be 
designated as the minimum number of contention-winner sessions for 
the other LU. This partitioning allows two LUs to divide a group of 
parallel sessions between them such that each LU is assured of being 
the contention winner of a minimum number of the sessions. 

The LU initiating the activation of a parallel session designates that 
it be the contention winner or contention loser. Details of how the 
initiating LU determines whether it is to be the contention winner or 
loser of a session are given in the notes in the descriptions of the 
CHANGE_SESSION_LIMIT and INITIALIZE_SESSIQN_LIMIT verbs. The LU 
responding to the activation of a parallel session always accepts the 
designated polarity. 

Sessions can be activated by means of certain control-operator verbs* 
and as a result of allocation requests. The control-operator verbs 
that can cause sessions to be activated are CHANGE_SESSION_LIMIT* 
INITIALIZE_SESSIGN_LIMIT* and ACTIVATE_SESSION. Refer to the 
descriptions of these verbs for more details about session acti¬ 
vation. 

Note: The contention-winner polarity of sessions assigned the 
SNA-defined mode name* SNASVCMG* is not negotiable. That is* the LU 
responding to the activation of an SNASVCMG session always accepts the 
designated polarity. 


Specific details are given in SNA Format and Protocol Reference 
Manual: Architecture Logic for LU Type 6.2 . 
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VERB DESCRIPTIONS 


The control-operator verbs are divided into the following subcatego¬ 
ries: 


Change number of sessions verbs 
Session control verbs 
LU definition verbs 

The detailed descriptions of the control-operator verbs follow. 
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CHANGE NUMBER OP SESSIONS VERBS 


This subcategory of control-operator verbs consists of four verbs 
called the change-number-of-sessions# or CNOS# verbs* The CNOS verbs 
change the (LU#mode) session limit# which controls the number of LU-LU 
sessions per mode name that are available between two LUs for allo¬ 
cation to conversations. The CNOS verbs apply to both single- and 
parallel-session connections. 

For single sessions and SNASVCMG sessions# the CNOS verbs change the 
(LU#mode) session limit only at the local LU. The remote LU is not 
involved in processing the change. The CNOS verbs that a control- 
operator transaction program may issue for a single session or 
SNASVCMG session are: 

INITIALIZE SESSION_LIMIT 
RESET_SESSION_LIMIT 

For parallel sessions# the CNOS verbs change the (LU#mode) session 
limit as well as other CNOS parameters of the LUs# and both LUs are 
involved in processing the changes. These other CNOS parameters con¬ 
trol the minimum number of contention-winner LU-LU sessions for each 
LU# control which LU is responsible for selecting and deactivating 
LU-LU sessions when the (LU#mode) session limit is decreased or reset# 
and control the draining of allocation requests when the (LU#mode) 
session limit is reset. 

The two LUs cooperate in the execution of the CNOS verbs by means of a 
CNOS request and CNOS reply. The LU executing the control-operator 
transaction program sends a CNOS request to the partner LU. The part¬ 
ner LU invokes an SNA service transaction program called the "CNOS 
service transaction program" (see "Appendix D. List of SNA Service 
Transaction Programs”)# which causes the partner LU to process the 
CNOS request and send back a CNOS reply. The CNOS request and reply 
are sent on a basic conversation# referred to in this chapter as the 
"CNOS conversation." The CNOS conversation is normally allocated on 
an SNASVCMG session. However# if an SNASVCMG session is not active# 
because of session outage for example# the CNOS conversation may be 
allocated on another active session. 

The LU that sends the CNOS request i s referred to as the source LU ; 
the LU that receives the CNOS request is referred to as the target LU . 
The execution of a CNOS verb by the two LUs is considered a CNOS 
transaction. The role of the LU as a source LU or target LU lasts for 
the duration of the CNOS transaction. 

The CNOS verbs that a control-operator transaction program may issue 
for parallel sessions are: 

CHANGE_SESSION LIMIT 
INITIALIZE_SESSION_LIMIT 
RESET_SESSION_LIMIT 

Only a transaction program that has CNOS privilege may issue these 
verbs. The program is designated to have CNOS privilege when it is 
defined to the local LU (see the DEFINE_TP verb). 

The CNOS verb that the CNOS service transaction program issues for 
parallel sessions is: 

PROCESSESESSION_LIMIT 

The detailed descriptions of the CNOS verbs follows. 
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CHANGE_SESSION_LIMIT 

Changes the (LU*mode) session limit and contention-winner polarities 
for parallel-session connections. The verb applies to the group of 
sessions with the specified mode name between this (source) LU and the 
specified (target)^ LU. The new (LU*mode) session limit and conten¬ 
tion-winner polarities are enforced until changed by a subsequent 
CNOS verb. As a consequence of changing the (LU*mode) session limit 
and contention-winner polarities* LU-LU sessions with the specified 
mode name may be activated or deactivated to conform to the new ses¬ 
sion limit and polarities. 


CHANGE_SESSION_LIMIT 


Supplied Parameters: 

LU_NAHE ( variable ) 

MODE_NAME ( variable ) 
LILMODE_session_limit ( variable ) 
MIN_CQNWINNERS_SOURCE ( variable ) 
MlN_CQNWINNERS_TARGET ( variable ) 


RESPONSIBLE ( SOURCE ) 
( TARGET ) 


Returned Parameters; 
RETURN.CODE ( variable ) 
t 


Supplied Parameters: 

LU_NAME specifies the name of the target LU to which the change in 
session limit and polarities applies. The LU name is a name that is 
valid as the LU__NAME parameter of the ALLOCATE verb (see "ALLOCATE" in 
Chapter 4). 

MODE_NAME specifies the mode name for which the session limit and 
polarities are to be changed. The specified mode name cannot be the 
SNA-defined mode name* SNASVCMG. 

LU_MODE_SESSION_LIMIT specifies the (LU*mode) session limit* that is* 
the maximum number of sessions to be allowed* between the source LU 
and target LU* for the specified mode name. 

The specified session limit must be greater than 0. The target LU can 
negotiate this parameter to a value greater than 0 and less than the 
specified session limit. The specified session limit* or the negoti¬ 
ated session limit if it is negotiated* becomes the new session limit. 

The value specified on this parameter must be greater than or equal to 
the sum of the values specified on the MIN CONWINNERS_SOURCE and 
MIN_CQNWINNERS_TARGET parameters. 

MXN_CONI4INNERS_SOURCE specifies the number of sessions of which the 
source LU is designated to be the contention winner. The specified 
number must be 0 or greater. The specified number* or the negotiated 
number if it is negotiated* becomes the new minimum number of conten¬ 
tion-winner sessions for the source LU. The sum of this number and 
the target LU's new minimum number of contention-winner sessions can¬ 
not exceed the new session limit. 

When the specified number is greater than 1/2 the new session limit 
(rounded downward)* the target LU can negotiate this parameter to a 
number greater than or equal to 1/2 the new session limit and less 
than the specified number. When the specified number is less than or 
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CHANGERSESSION_LIMIT 

equal to 1/2 the new session limit, the target LU cannot negotiate 
this parameter. 

MIN_CONWINNERS_TARGET specifies the number of sessions of which the 
target LU is designated to be the contention winner. The specified 
number must be 0 or greater. The specified number, or the negotiated 
number if it is negotiated, becomes the new minimum number of conten¬ 
tion-winner sessions for the target LU. The sum of this number and 
the source LU f s new minimum number of contention-winner sessions can¬ 
not exceed the new session limit. 

The target LU can negotiate this parameter to a number less than or 
equal to the new session limit minus the new minimum number of conten¬ 
tion-winner sessions for the source LU. 

RESPONSIBLE specifies which LU is responsible for selecting and deac¬ 
tivating sessions as a result of a change that decreases the session 
limit or the maximum number of contention-winner sessions for the 
source or target LU; see note 4 for details. If no sessions need to be 
deactivated, this parameter is ignored. 

• SOURCE specifies that the source LU is responsible. The target LU 
cannot negotiate this argument. 

• TARGET specifies that the target LU is responsible. The target LU 
can negotiate this argument to SOURCE, in which case the source LU 
becomes responsible. 

The responsible LU can deactivate a session when both LUs are finished 
using the session. This verb will not terminate active conversations. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return .code indicates the result of verb exe¬ 
cution. 

• OK (with one of the following subcodes) 

AS_SPECIFIED 

AS.NEGQTIATED 

• ALLOCATI0N_ERR0R 

• COMMAND_RACE_REJECT 

• LU_MODE_SESSION_LIMIT ZERO 

• LU_SESSION_LIMIT_EXCEEDED 

• PARAMETER_ERROR (for one of the following reasons) 

— Invalid LU name 

— Invalid mode name 

• REQUEST_EXCEEDSJ1AX_ALL0WED 

• RESOURCE_FAILURE_NO_RETRY 

• UNRECOGNIZED J10DE_NAME 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have CNOS privilege. 

• MODE NAME specifies the SNA-defined mode name, SNASVCMG. 

• LU_MODE_SESSION_LIMIT specifies 0. 

• MIN_CQNWINNERS_TARGET is specified and not supported. 

• The sum of MIN_CONWINNERS_SOURCE and MIN_CQNWINNERS_TARGET speci¬ 
fies a number greater than LU_MODE_SESSION_LIMIT. 

• RESPONSIBLE(TARGET) is specified and not supported. 

Notes: 

1. This verb applies only to parallel-session connections. 

2. All of the parallel sessions between two LUs can be partitioned 
into groups, with all the sessions in a group having the same mode 
name. This verb is used to change the limits on the number of 
active sessions that can exist concurrently within a mode-name 
group between the source LU and target LU. The limits imposed on 
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the number of active parallel sessions mi thin a mode-name group 
are: 

a. The number of active sessions cannot exceed the (LU*mode) 
session limit. 

b. The number of active contention-Minner sessions for the 
source LU cannot exceed the (LU*mode) session limit minus the 
minimum number of contention-Minner sessions for the target 
LU. 

c. The number of active contention-Minner sessions for the tar¬ 
get LU cannot exceed the (LU*mode) session limit minus the neM 
minimum number of contention-Minner sessions for the source 
LU. 

As a result of issuing this verb* sessions may be activated* deac¬ 
tivated* or both to conform to the neM limits. The next tMo notes 
describe the conditions under Mhich sessions may be activated or 
deactivated. 

The source or target LU may activate parallel sessions* up to the 
limits given in note 2* as folloMs: 

• It may activate neM contention-Minner sessions Mhen the num¬ 
ber of its active contention-Minner sessions is less than the 
neM (LU*mode) session limit minus the neM minimum number of 
contention-Minner sessions for its partner LU. 

• It may activate neM contention-loser sessions Mhen the number 
of its active contention-loser sessions is less than the neM 
(LU*mode) session limit minus its own neM minimum number of 
contention-Minner sessions. 

The LU may activate contention-Minner or -loser sessions in 
response to allocation requests or by means of the ACTI- 
VATE_SESSION verb. Also, it may activate contention-Minner ses¬ 
sions automatically* after completion of this verb* up to the 
lesser of the its neM minimum number of contention-Minner ses¬ 
sions and its automatic-activation limit currently in effect (see 
the DEFINE_MODE verb). 

Parallel sessions are deactivated Mhen this verb causes one or 
more of the limits given in note 2 to be exceeded. The LU respon¬ 
sible for selecting and deactivating sessions is designated by 
the RESPONSIBLE parameter. The responsible LU deactivates ses¬ 
sions until all three limits given in note 2 are met. When all 
three limits are met* no more sessions are deactivated. 

The responsible LU deactivates sessions that are not allocated to 
conversations. If a session to be deactivated is currently allo¬ 
cated to a conversation* the responsible LU Maits until the con¬ 
versation is deallocated and then deactivates the session. 

The responsible LU can deactivate only those sessions that are in 
excess of an LU's minimum number of contention-Minner sessions. 
If the number of currently active contention-Minner sessions for 
the source or target LU is less than or equal to its minimum num¬ 
ber of contention-Minner sessions* none of its contention-Minner 
sessions are deactivated. 
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INITIALIZE_SESSION_LIMIT 

Establishes the initial (LU#mode) session limit for single- or paral¬ 
lel-session connections# and the contention-winner polarities for 
parallel-session connections. The verb applies to the group of ses¬ 
sions with the specified mode name between the source LU and the tar¬ 
get LU. The new (LU#mode) session limit and contention-winner 
polarities are enforced until changed by a subsequent CNOS verb. As a 
consequence of initializing the session limit# one or more LU-LU ses¬ 
sions with the specified mode name may be activated. 



Supplied Parameters: 

INXTXALXZE_SESSZON_LXI1IT 

LU.NAME ( variable ) 


NODE NAME ( variable ) 


( 'SNASVCMG* ) 


LU_M0DE_SESSXQN_LXMXT ( variable I 


MIN_CONUXNNERS_SOURCE ( variable ) 


MIN_CONMXNNERS_TARGET ( variable ) 


Returned Parameters: 


RETURN_CODE ( variable ) 


9 


supplied Parameters; 

LU_NAME specifies the name of the target LU to which the initializa¬ 
tion of session limit and polarities applies. The LU name is a name 
that is valid as the LU_NAME parameter of the ALLOCATE verb (see "AL¬ 
LOCATE” in Chapter 4). 

MODE_NAME specifies the mode name for which the session limit and 
polarities are to be initialized. 

• variable contains the mode name. 

• V SNASVCMG V specifies the SNA-defined mode name# which is used for 
exchanging the CNOS request and reply when the source LU and tar¬ 
get LU are connected by parallel sessions. 

LU_MODE m SESSXON_LXMXT specifies the (LU#mode) session limit for par¬ 
allel-session connections# that is# the maximum number of parallel 
sessions to be allowed# between the source LU and target LU# for the 
specified mode name. 

The specified session limit must be greater than 0. The target LU can 
negotiate this parameter to a value greater than 0 and less than the 
specified session limit. The specified session limit# or the negoti¬ 
ated session limit if it is negotiated# becomes the new session limit. 

The value specified on this parameter must be greater than or equal to 
the sum of the values specified on the MIN_C0NWINNERS_S0URCE and 
MIN_CONWINNERS_TARGET parameters. 

For single-session connections# the specified (LU#mode) session limit 
must be 1. 

For the SNASVCMG mode name# the specified (LU#mode) session limit must 
be 2. 

HXN_C0NI4XNNERS_S0URCE specifies the number of parallel sessions of 
which the source LU is designated to be the contention winner. The 
specified number must be 0 or greater. The specified number# or the 
negotiated number if it is negotiated# becomes the new minimum number 
of contention-winner sessions for the source LU. The sum of this num- 
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ber and the target LU's new minimum number of contention-winner ses¬ 
sions cannot exceed the new session limit. 

When the specified number is greater than 1/2 the new session limit 
(rounded downward)* the target LU can negotiate this parameter to a 
number greater than or equal to 1/2 the new session limit and less 
than the specified number. When the specified number is less than or 
equal to 1/2 the new session limit* the target LU cannot negotiate 
this parameter. 

For single-session connections* the specified minimum number of con¬ 
tention-winner sessions for the source LU may be 0* or it may be 1 if 
the value specified on the MIN_CONWINNER_TARGET parameter is 0. 

For the SNASVCMG mode name* the specified minimum number of conten¬ 
tion-winner sessions for the source LU must be 1. 

MIN_CONWINNERS_TARGET specifies the number of parallel sessions of 
which the target LU is designated to be the contention winner. The 
specified number must be 0 or greater. The specified number* or the 
negotiated number if it is negotiated* becomes the new minimum number 
of contention-winner sessions for the target LU. The sum of this num¬ 
ber and the source LU's new minimum number of contention-winner ses¬ 
sions cannot exceed the new session limit. 

The target LU can negotiate this parameter to a number less than or 
equal to the new session limit minus the new minimum number of conten¬ 
tion-winner sessions for the source LU. 

For single-session connections* the specified minimum number of con¬ 
tention-winner sessions for the target LU may be 0* or it may be 1 if 
the value specified on the MIN_CONWINNER_SOURCE parameter is 0. 

For the SNASVCMG mode name* the specified minimum number of conten¬ 
tion-winner sessions for the target LU must be 1. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of verb exe¬ 
cution. 

• OK (with one of the following subcodes) 

AS_SPECIFIED 

AS_NEGOTIATED 

• ALL0CATI0N_ERR0R 

• COMMAND_RACE_REJECT 

• LU_MODE_SESSION_LIMIT_CLOSED 

• LU_MODE_SESSION_LIMIT_NOT_ZERO 

• LU_SESSION_LIMIT_EXCEEDED 

• PARAMETER_ERROR (for one of the following reasons) 

— Invalid LU name 

— Invalid mode name 

• REQUEST_EXCEEDS_MAX_ALLOWED 

• RESOURCE_FAILURE_NO_RETRY 

• UNRECOGNIZED_MODE_NAME 

ABEND Conditions? 

Parameter Check 

• The program issuing this verb does not have CNOS privilege. 

• LU_MODE_SESSION_LIMIT specifies a value greater than 1 for a 
single-session connection. 

• MODE_NAMECSNASVCMG') is specified and LU_MODE_SESSION_LIMIT, 
MIN_CONWINNERS_SOURCE, and MIN_CONWINNERS_TARGET do not specify 
2* 1* and 1* respectively. 

• LU_MODE_SESSION_LIMIT specifies 0. 

• MIN.CONWINNERS TARGET is specified and not supported. 

• The sum of MIN_CONWINNERS_SOURCE and MIN_CONWINNERS_TARGET speci¬ 
fies a number greater than LU_M0DE_SESSI0N_LIMIT. 
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XNXTXALXZE_SESSXON_LXMXT 

Notes: 

1. The (LU#mode) session limit for a single-session connection is 
initialized only locally at the source LU; a CNOS request and 
reply are not exchanged between the two LUs. Thus# the INITIAL- 
IZE_SESSION_LIMIT verb must be issued at both LUs before either LU 
can~activate the corresponding session* From each LU f s perspec¬ 
tive# each is the source LU for the processing of this verb. 

2. For a single-session connection# the contention-winner polarity 
for the session is determined from the MIN_CGNWINNER_50URCE and 
MIN_CONWINNER_TARGET parameters on the verbs issued at both LUs. 
The~LU activating the session: 

• Requests that it be the contention winner when the verb issued 
at that LU specifies MIN_CONWINNERS_TARGET(0) . 

• Requests that it be the contention loser when the verb speci¬ 
fies MIN_CQNWINNERSJTARGET(1). 

The partner LU: 

• Accepts the requested contention-winner polarity when the 
verb issued at that LU specifies MIN_CONWINNERS_SOURCE<0). 

• Negotiates the polarity so that it is the contention winner 
when the verb specifies MIN_CONWINNERS_SOURCE(1). 

3. For a single-session connection# the LU may have more than one 
mode defined at a time to a partner LU. Each (LU#mode) session 
limit can be either 0 or 1# and more than one (LU#mode) session 
limit can be 1# concurrently# for the partner LU. This permits 
the LU to activate a session for any of the modes that have an 
(LU#mode) session limit of 1; however# only one session can be 
active at a time. 

4. For a parallel-session connection to a target LU# the (LU#mode) 
session limit and contention-winner polarities for the SNASVCMG 
mode name and target LU must be initialized before (LU#mode) ses¬ 
sion limit and contention-winner polarities can be initialized 
for any other mode name for the target LU. The (LU#mode) session 
limit and contention-winner polarities for the SNASVCMG mode name 
and target LU are initialized only at the source LU# a CNOS 
request and reply are not exchanged between the two LUs. 

The (LU#mode) session limit and contention-winner polarities for 
the SNASVCMG mode name must be initialized at both the source LU 
and target LU before either LU can activate the corresponding ses¬ 
sions; a CNOS request and reply are not exchanged between the two 
LUs. From each LU f s perspective# each is the source LU for the 
processing of INITIALIZE_SESSION_LIMIT with 

MODE_NAME( f SNASVCMG 1 ). 

5. All the parallel sessions between two LUs can be partitioned into 
groups# with all the sessions in a group having the same mode 
name. This verb can be used to initialize the limits on the num¬ 
ber of active parallel sessions that can exist concurrently with¬ 
in a mode-name group between the source and target LUs. The 
limits imposed on the number of active parallel sessions within a 
mode-name group are: 

a. The number of active sessions cannot exceed the (LU#mode) 
session limit. 

b. The number of active contention-winner sessions for the 
source LU cannot exceed the (LU#mode) session limit minus the 
minimum number of contention-winner sessions for the target 
LU. 

c. The number of active contention-winner sessions for the tar¬ 
get LU cannot exceed the (LU#mode) session limit minus the new 
minimum number of contention-winner sessions for the source 
LU. 
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As a result of issuing this verb* parallel sessions may be acti¬ 
vated to conform to the new limits. 

For single- and parallel-session connections* an LU may activate 
contention-winner or -loser sessions in response to allocation 
requests or by means of the ACTIVATE_SESSION verb. Also* it may 
activate contention-winner sessions automatically* after com¬ 
pletion of this verb* up to the lesser of the its new minimum num¬ 
ber of contention-winner sessions and its automatic-activation 
limit currently in effect. 
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RESET_SESSION_LIMT 

Resets to 0 the (LU*mode) session limit for single or parallel-session 
connections* and the contention-winner polarities for the parallel- 
session connections. The verb applies to the group of sessions with 
the specified mode name* or all mode names* between the source LU^and 
the target LU. The reset (LU»mode) session limit and contention- 
winner polarities are enforced until initialized by a subsequent INI- 
TIALIZE_SESSION_LIMIT verb. As a consequence of resetting the 
session limit and polarities* all active sessions with the specified 
mode name* or all mode names* are deactivated. 


RESET_SESSION_LXMXT 


supplied Parameters: 
LU.NAHE C variable ) 


( ALk ) 

NODE NAME ( ONE ( variable ) ) 

I ” ( ONE C 'SNASVCMG' ) ) 

[ RESPONSIBLE ( SOURCE 1 1 
C TARGET ) I 

[ DRAXN.SOURCE C NO ) 1 

C YES ) J 

f DRAIN TARGET C NO > 1 

L “ t YES ) J 

[ FORCE C NO } 

C YES ) 


Returned Parameters; 
RETURN_CODE ( variable ) 
5 


Supplied Parameters; 

LUJMME specifies the name of the target LU to which the resetting of 
the session limit and polarities applies. The LU name is a name that 
is valid as the LU_NAME parameter of the ALLOCATE verb (see "ALLOCATE" 
i n Chapter 4). 

MODERN AM E specifies the mode name for which the session limit and 
polarities are to be reset to 0. 

• ALL specifies that the session limit and polarities for all mode 
names that apply to the target LU are to be reset to Op except for 
the SNA-defined mode name# SNASVCMG# which remains unchanged. 

• ONE(variable) specifies that the session limit and polarities for 
only the specified mode name are to be reset to 0. 

• ONE ( f SNASVCMG f ) specifies the SNA-defined mode name# which is 
used for exchanging the CNOS request and reply when the source LU 
and target LU are connected by parallel sessions. 

RESPONSIBLE specifies which LU is responsible for deactivating the 
sessions as a result of resetting the session limit for parallel-ses¬ 
sion connections. This parameter is not applicable to single-session 
connections or the SNASVCMG sessions. 

• SOURCE specifies that the source LU is responsible. The target LU 
cannot negotiate this argument. 
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• TARGET sped f i es that the target LU is responsible* The target LU 
can negotiate this argument to SOURCE* in which case the source LU 
becomes responsible* 

The parameters DRAIN_SOURCE and DRAIN_TARGET determine when the 
responsible LU can deactivate the sessions: 

• If an LU is to drain its allocation requests* it continues to 
allocate conversations to active sessions* The responsible LU 
deactivates a session only when the conversation allocated to the 
session is deallocated and no request is awaiting allocation to 
any session with the specified mode name* The allocation of an 
awaiting request takes precedence over the deactivation of a ses¬ 
sion. 

• If an LU is not to drain its allocation requests* the responsible 
LU deactivates a session as soon as the conversation allocated to 
the session is deallocated. If no conversation is allocated to 
the session* the responsible LU deactivates the session imme¬ 
diately* 

In no case* however* does this verb force deallocation of active con¬ 
versations. 

The RESPONSIBLE and M0DE_NAME parameters are interrelated* as fol¬ 
lows: 

• If M0DE_NAME(ALL) is specified* RESPONSIBLE is ignored for those 
mode names for which the session limit is currently 0* 

• If M0DE_NAME(0NE(variable)) is specified and the current session 
limit for that mode name is 0* RESPONSIBLE is ignored* 

DRAXN_SOURCE specifies whether the source LU can drain its allocation 
requests. For parallel-session connections* the target LU cannot 
negotiate this parameter. This parameter is not applicable to the 
SNASVCMG sessions* 

• NO specifies that the source LU cannot drain its allocation 
requests. All requests currently awaiting allocation* or subse¬ 
quently issued* at the source LU are rejected with a return code 
indicating the session limit is 0. 

• YES specifies that the source LU can drain its allocation 
requests* The source LU continues to allocate conversations to 
the sessions until no requests are awaiting allocation* at which 
time its draining is ended. All allocation requests issued at the 
source LU after draining is ended are rejected with a return code 
indicating the session limit is 0* 

For parallel-session connections* the DRAIN_SOURCE and M0DE_NAME 
parameters are interrelated* as follows: 

• If M0DE_NAME(ALL) and DRAIN_SOURCE(YES) are specified* 

DRAIN_SOURCE is ignored for those mode names for which the session 
limit is currently 0. 

• If MODE_NAMECALL) and DRAIN_SOURCECNO) are specified, 

DRAIN_SOURCE is accepted for all mode names* regardless of the 
current session limit. 

• If M0DE_NAME(ONE(variable)) is specified* the current session 

limit for that mode name is 0* and DRAINJjOURCE(YES) is currently 
in effect* DRAIN_SOURCE(NQ) if specified causes the source LU*s 
draining to terminate. 

• If M0DE_NAME(0NE(variable)) is specified* the current session 

limit for that mode name is 0* and DRAIN_S0URCE(N0) is currently 
in effect* DRAIN_SOURCE(NO) must be specified* 

DRAXN_TARGET specifies whether the target LU can drain its allocation 
requests* This parameter is not applicable to the SNASVCMG sessions. 
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• NO specifies that the target LU cannot drain its allocation 
requests. All requests currently awaiting allocation# or subse¬ 
quently issued^ at the target LU are rejected with a return code 
indicating the session limit is 0. For parallel-session con¬ 
nections# the target LU cannot negotiate this argument. 

• YES specifies that the target LU can drain its allocation 
requests. The target LU continues to allocate conversations to 
the sessions until no requests are awaiting allocation# at which 
time its draining is ended. All allocation requests issued at the 
target LU after draining is ended are rejected with a return code 
indicating the session limit is 0. For parallel-session con¬ 
nections, the target LU can negotiate this argument to NO# in 
which case the target LU cannot drain its allocation requests. 

For parallel-session connections# the DRAIN_TARGET and M0DE_NAME 
parameters are interrelated# as follows: 

• If MQDE_NAME(ALL) and DRAIN_TARGET(YES) are specified# 

DRAIN_TARGET is ignored for those mode names for which the session 
limit is currently 0. 

• If MQDE_NAME(ALL) and DRAIN.TARGETCNO) are specified# 

DRAIN_TARGET is accepted for all mode names# regardless of the 
current session limit. 

• If MODE_NAME(ONE(variable)) is specified# the current session 

limit for that mode name is 0# and DRAIN_TARGETCYES) is currently 
in effect# DRAIN_TARGET(NO) if specified causes the target LU's 
draining to terminate. 

• If MODE_NAME(ONE(variable)) is specified# the current session 

limit for that mode name is 0# and DRAIN_TARGET(NO) is currently 
in effect# DRAIN_TARGET(YES) if specified can be either accepted 
by the target LU or negotiated to NO. If accepted# the target LU 
can drain its remaining allocation requests if draining has not 
already ended. 

FORCE specifies whether the source LU i s to force the resetting of its 
session limit when certain error conditions occur that prevent suc¬ 
cessful exchange of the CNOS request and reply. This parameter is not 
applicable to single-session connections or the SNASVCMG sessions. 

• NO specifies that the session limit is to be reset only upon suc¬ 
cessful completion of the exchange of the CNOS request and reply. 

• YES specifies that the session limit is to be reset upon either 
successful or unsuccessful completion of the exchange of the CNOS 
request and reply# except for certain error conditions (see the 
RETURN_CODE parameter). If a forced reset occurs# the source LU's 
session limit is reset# and RESPONSIBLECSOURCE) and 
DRAIN_S0URCE(N0) are assumed (regardless of what the respective 
parameters specify). The target LU f s CNOS parameters may not be 
changed# depending on the error condition and when it occurred 
during the CNOS exchange. 

Returned Parameters; 

RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of verb exe¬ 
cution. The FORCE parameter determines which of the following return 
codes can be returned to the program. 

• If FORCE(NO) is specified# one of the following return codes is 
returned: 

— OK (with one of the following subcodes) 

— AS_SPECIFIED 
— AS_NEGOTIATED 
ALL0CATI0N_ERR0R 
COMMAND_RACE_REJECT 
LUJ10DE_SESSI0N_LIMIT_CL0SED 
- PARAMETER_ERROR (for one of the following reasons) 

— Invalid LU name 
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— Invalid mode name 

RESOURCE_FAILURE_NO_RETRY 

UNRECOGNIZED_MODE_NAME 

• If FORCE(YES) is specified* one of the following return codes is 
returned: 

— OK (with one of the following subcodes) 

— AS_SPECIFIED 
— AS_NEGOTIATED 
— FORCED 
COMMAND_RACE_REJECT 

— PARAMETER_ERROR (for one of the following reasons) 

— InvalTd LU name 
— Invalid mode name 

ABEND Conditions: 

Parameter Check 

• The program issuing this verb does not have CNOS privilege. 

• MODE_NAME(ONE(*SNASVCMG')) is specified and one or more (LU.mode) 
session limits for the target LU are not 0. 

• M0DE_NAME(0NE<variable)) and DRAIN_SOURCE(YES) are specified, the 
current (LU,mode) session limit is 0, and DRAIN_S0URCE(N0) is 
currently in effect. 

• RESPONSIBLE(TARGET) is specified and not supported. 

• DRAIN_TARGET(NO) is specified and not supported. 

• FORCE(YES) is specified and not supported. 

Notes: 

1. The (LU#mode) session limit for a single-session connection to a 
target LU is reset only at the source LU; a CNOS request and reply 
are not exchanged between the two LUs. The source LU deactivates 
the session# if it is active# in accordance with the DRAIN_SOURCE 
and DRAIN_TARGET parameters. 

2. For parallel-session connections# when a mode name is specified 
other than the SNA-defined mode name# SNASVCMG# or when ALL mode 
names are indicated# the responsible LU deactivates the sessions 
associated with the specified mode name# or all mode names other 
than SNASVCMG# in accordance with the DRAIN_SOURCE and 
DRAIN_TARGET parameters. The (LU#mode) session limits and con¬ 
tention-winner polarities for all mode names other than SNASVCMG 
must be reset before issuing this verb with the SNASVCMG mode name 
specified. 

3. When the SNASVCMG mode name is specified# the (LU#mode) session 
limit and contention-winner polarities for the SNASVCMG mode name 
are reset only at the source LU# a CNOS request and reply are not 
exchanged between the two LUs. The source LU deactivates the ses¬ 
sions associated with the SNASVCMG mode name as soon as all other 
active sessions between the source LU and target LU are deacti¬ 
vated. If no other sessions between the two LUs are active# the 
source LU immediately deactivates the sessions associated with 
the SNASVCMG mode name. 

4. This verb can be issued when the (LU#mode) session limit is 0. In 
particular# this verb may be issued multiple times without issu¬ 
ing an intervening INITIALIZE_SESSION_LIMIT verb. For example# 
if this verb was first issued specifying DRAIN_TARGET(YES) and 
subsequently it is decided to disallow further draining by the 
target LU# this verb can be issued a second time specifying 
DRAINJTARGET(NO). When the (LU#mode) session limit is already 0, 
the RESPONSIBLE parameter is ignored; the LU (SOURCE or TARGET) 
specified on the first RESET_SESSION_LIMIT remains responsible 
for deactivating sessions. 
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PROCESS.SESSXON.LXHXT 

Processes the session limit* contention-winner polarities* and 
related CNOS parameters from the source LU and* if necessary* negoti¬ 
ates them to values acceptable to the target LU. 



Supplied Parameters: 

PROCESS_SESSION_LXMXT 

RESOURCE ( variable ) 


Returned Parameters: 

LU.NAME ( variable ) 

HODE.NAHE ( variablel variable2 ) 

RETURN_CODE ( variable I 


» 


Supplied Parameters: 

RESOURCE specifies the resource ID of the conversation that started 
this program. 

Returned Parameters: 

LU^NAME specifies the variable in which is returned the name of the 
source LU. 

MODE_NAME specifies the variables in which are returned an indication 
of whether one or all mode names are affected* and* if one* the spe¬ 
cific mode name. 

• variablel is the variable in which is returned an indication of 
whether one or all mode names associated with the source LU are 
affected. 

— ONE indicates a specific mode name is affected. The mode name 
is returned in variable2. 

— ALL indicates all mode names are affected. Nothing is placed 
in variable2. 

• variable2 is the variable in which is returned the specific mode 
name when only one is affected. 

RETURN_CODE specifies the variable in which a return code is returned 
to the program. The return code indicates the result of verb exe¬ 
cution. 

• OK (with one of the following subcodes) 

AS_SPECIFIED 

AS^NEGOTIATED 

• RESOURCE_FAILURE_NO_RETRY 

ABEND Conditions: 

Parameter Check 

The program issuing this verb is not the SNA service transaction 
program identified as hex 06F1. 

Notes: 

1. This verb applies only to parallel session connections. 

2. This verb is issued by an SNA service transaction program called 
the ”CN0S service transaction program*” identified with the name 
of hex 06F1. The CNOS service transaction program is invoked at 
the target LU as a result of a CNOS verb being issued at the 
source LU. The CNOS service transaction program then issues this 
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verb in order to initiate the target LU f s processing of the CNOS 
request sent by the source LU. 

The program issues the DISPLAYJ10DE verb in order to obtain the 
new session limit* contention-winner polarities* and related CNOS 
parameters. 
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SESSION CONTROL VERBS 


This subcategory of control-operator verbs consists of two verbs used 
for session control > one that activates an LU-LU session and one that 
deactivates an LU-LU session. The LU executing the verb is designated 
the source LU and is responsible for the session activation or deacti¬ 
vation. The other LU for the session is the target LU. These verbs 
are: 


ACTIVATE^SESSION 
DEACTIVATEDESSION 

Only a transaction program that has session-control privilege may 
issue these verbs. The program is designated to have session-control 
privilege when it is defined to the local LU (see the DEFINE_TP verb). 

The detailed descriptions of these verbs follows. 
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ACTIVATEDESSXON 


Activates a session with the specified mode name to the target LU. 
The session is activated as a contention winner for either the source 
LU or target LU, 



Supplied Parameters: 

ACTXVATE.SESSXON 

LU.NAME ( variable ) 


MODE NAME ( variable ) 

C 'SNASVCMG' ) 


Returned Parameters: 

RETURN_CODE ( variable ) 


; 


Supplied Parameters: 

LU_NAME specifies the name of the target LU to which the session is to 
be activated. This LU name is any name by which the source LU knows 
the target LU for the purpose of activating a session. The source LU 
transforms this locally-known LU name to an LU name used by the net¬ 
work* if the names are different, 

MODE_NAME specifies the mode name for the session, 

• variable contains the mode name. 

• 'SNASVCMG• specifies the SNA-defined mode name* which is used for 
exchanging the CNOS request and reply when the source LU and tar¬ 
get LU are connected by parallel sessions. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 
to the"" program. The return code indicates the result of verb exe¬ 
cution. 

• OK (with one of the following subcodes) 

AS_SPECIFIED 

A$_NEGOTIATED 

• ACTIVATIQN_FAILURE_NO_RETRY 

• ACTIVATION_FAILURE_RETRY 

• PARAMETER_ERROR (for one of the following reasons) 

— Invalid LU name. 

— Invalid mode name. 

• LUJ10DE_SES$I0N_LIMIT_ EXCEEDED 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have session-control priv- 
ilege. 

Notes: 

1. This verb can be used to activate a single session as a contention 
winner for either the source LU or the target LU. The LU to be the 
contention winner is established by means of the INITIAL- 
IZE_SESSION_LIMIT verb. 

2. This verb can be used to activate one or both parallel sessions 
for the SNASVCMG mode name to a target LU. The source LU is the 
contention winner for the first session* the target LU is the con¬ 
tention winner for the second session. 
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ACTIVATE^SESSION 


3. This verb can be used to activate a parallel session as a con¬ 
tention winner for either the source LU or the target LU. The 
session is activated as a contention winner for the source LU when 
the number of currently active contention-winner sessions for the 
source LU is less than the new (LU#mode) session limit minus the 
new minimum number of contention-winner sessions for the target 
LU. Otherwise# the session is activated as a contention winner 
for the target LU. 
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DEACTXVATE.SESSXON 

Deactivates the specified LU-LU session. The type of deactivation can 
be cleanup or normal. 



Supplied Parameters: 

DEACTXVATE.SESSXON 

sessxon.xd ( variable ) 


f TYPE ( CLEANUP ] 1 


[ ( NORMAL 1 J 


Returned Parameters: 


RETURN.CODE ( variable ) 


$ 


Supplied Parameters: 

SESSXON_ID specifies the identifier of the LU-LU session to be deacti¬ 
vated. 

TYPE specifies the type of deactivation. 

• CLEANUP specifies that the session is to be deactivated imme¬ 
diately* regardless of whether a conversation is currently allo¬ 
cated to the session. 

• NORMAL specifies that the session is to be deactivated normally* 
after the conversation currently allocated to the session is 
deallocated. If no conversation is currently allocated to the 
session* normal deactivation begins immediately. 

Returned Parameters: 

RETURN_CODE specifies the variable in which a return code is returned 

to the program. The return code indicates the result of verb exe- 

cution. 

• OK 

• PARAMETER_ERROR (for the following reason) 

— The specified session identifier is not assigned to a cur¬ 
rently active session. 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have session-control priv- 
ilege. 
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LU DEFINITION VERBS 


This subcategory of control-operator verbs consists of the following 
verbs# which are used to define or modify the local LU v s operating 
parameters# examine the parameters# and delete the parameters. These 
verbs are: 

DEFINE LOCAL.LU 

DEFINE_REMOTE_LU 

DEFINEJ10DE 

DEFINE_TP 

DISPLAY_10CAL_LU 

DISPLAY_REMOTE_LU 

DISPLAY_MODE 

DISPLAY_TP 

DELETE 

The execution of these verbs involves only the local LU. They do not 
cause any information to be sent outside the LU. 

Some of the local LU f s operating parameters can be added# modified# or 
deleted only under appropriate conditions. An attempt to alter any of 
these parameters when conditions are inappropriate is an error# caus¬ 
ing the LU to return the PARAMETER_ERROR return code on the verb. The 
parameters that are restricted in this way and the corresponding 
errors are identified in the verb descriptions. 

The DEFINE verbs may be issued multiple times to initialize or update 
the local LU's operating parameters. The first time a verb parameter 
is specified# the LU f s corresponding operating parameter is initial¬ 
ized# thereafter# it is changed. The following notes apply to all 
verb parameters# except where stated otherwise in the individual verb 
descriptions: 

• If the LU's operating parameter is not currently defined and the 
corresponding verb parameter is specified# the operating parame¬ 
ter is initialized with the supplied value. 

• If the LU's operating parameter is not currently defined and the 
corresponding verb parameter is omitted# the operating parameter 
remains undefined. 

• If the LU f s operating parameter is currently defined and the cor¬ 
responding verb parameter is specified# the operating parameter 
value is replaced with the supplied value. 

• If the LU f s operating parameter is currently defined and the cor¬ 
responding verb parameter is omitted# the operating parameter 
value remains unchanged. 

The DISPLAY verbs return current values of the local LU ? s operating 
parameters. When a DISPLAY verb is issued specifying a parameter that 
is not currently defined at the local LU# a null value is returned. 

The DELETE verb deletes the local LU's operating parameters. After a 
parameter is deleted# it i s no longer defined at the local LU. 

Only a transaction program that has define privilege may issue the 
DEFINE verbs and DELETE verb# and only a program that has display 
privilege may issue the DISPLAY verbs. The program is designated to 
have define or display privilege when it is defined to the local LU 
(see the DEFINE_TP verb). The program that initially establishes 
define privilege for other programs has implicit define privilege. 

The detailed descriptions of these verbs follow. 
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DEFINE_LOCAL_LU 


Defines the fully qualified name for the local LU* and initializes or 
changes parameters that control the operation of the local LU. 


DEFINE_LOCAL_LU 


Supplied Parameters: 

FULLY_QUALIFIED_LU_NAME C variable ) 

[ LU_SESSION_LIMIT C NONE ) 

C VALUE ( variable ) ) 


( ADD ( USER.ZD C variable ) 
password C variable ) 
SECURITY PROFILE ( variable ) ) ) 

( DELETE ( user_id ( variable ) 

PROFILE ( variable ) ) ) 


MAP.NAME C ADD ( variable ) ) 

( DELETE ( variable ) ) 


Returned Parameters: 
RETURN.CODE C variable ) 


Supplied Parameters; 

FULLY_QUALIFIED_LU_NAME specifies the fully qualified name of the 
local LU. If the specified name is not currently defined* this verb 
defines the name by which the local LU is known throughout the net¬ 
work* replacing the current name if one exists* and initializes the 
LU-LU session limit. If the specified name is already defined* this 
verb changes the other parameter values. 

LU_SESSION_LIMIT specifies the LU-LU session limit for the total num¬ 
ber of sessions for the local LU. 

• NONE specifies that no limit is to be defined. 

• VALUE specifies a number representing the LU-LU session limit. 

SECURITY specifies to add or delete access security information that 
the local LU uses for conversation-level security verification of 
incoming allocation requests on an LU-wide basis. (Contrast this 
parameter with the SECURITY_REQUIRED and SECURITY_ACCES$ parameters 
of the DEFINE_JP verb.) The local LU updates a conversation-level 
security verification list from the information supplied on this 
parameter. The verification list consists of one or more user IDs and 
corresponding passwords* and zero or more profiles associated with 
each user ID. 

• ADD specifies to add access security information to the LU T s 
conversation-level security verification list. A user ID must be 
specified together with either* or both* a password or profile. 

— USER_ID specifies a user ID. If the user ID is not currently 
defined* a password must also be specified* and the LU adds 
the user ID* password* and profile (if specified) to its 
conversation-level security verification list. If the user 
ID is already defined* the list is updated with the password 
or profile. 

- PASSWORD specifies the password for this user ID. If the user 
ID is already defined* the password replaces the one current¬ 
ly defined. 
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— PROFILE specifies a profile for this user ID. If the user ID 
is already defined, the profile is added to the ones currently 
defined. 

• DELETE specifies to delete access security information from the 
LU’s conversation-level security verification list. The user ID 
may be specified alone or together with a profile. 

— USER__ID specifies the user ID. If a profile is not specified, 
the user ID and its associated password and profiles are 
deleted. If a profile is also specified, the user ID and its 
associated password and other profiles remain defined. 

— PROFILE specifies the profile to be deleted. 

MAP_NAME specifies to add or delete a map name that the local LU is to 
support for local data mapping. Local transaction programs may speci¬ 
fy this map name on the MAP_NAME parameter of the MC_SEND_DATA verb, 
and remote LUs may send this map name to the local LU over mapped con¬ 
versations. 

• ADD specifies the map name to be added. 

• DELETE specifies the map name to be deleted. 

Returned Parameters: 

RETURN_CODE returns an indication of the result of verb execution. 

• OK 

• PARAMETER_ERROR (for one of the following reasons) 

FULLY_QUALIFIED_LU_NAME specifies a value that is not a 
type-A symbol string. 

— LU_SESSION_LIMIT(VALUE(variable)) specifies a value that is 
less than the sum of .the (LU,mode) session limits currently in 
effect. 

- SECURITYCADDC...)) specifies a user ID, password, or profile 
that is not a symbol-string type (A, AE, 6R, or DB) that the 
product supports. 

— SECURITYCADDC...)) specifies only a user ID, or a password or 
profile but no user ID. 

SECURITYCDELETEC...)) specifies a user ID or profile that is 
not currently defined at the local LU. 

SECURITYCDELETEC...)) specifies only a profile. 

— MAP_NAME( ADDC variable)) specifies a map name that is not a 
symbol-string type CA, AE, or GR) that the product supports. 

— MAP_NAME(DELETE(variable)) specifies a map name that is not 
currently defined at the local LU. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have define privilege. 

Notes: 

1. This verb can be used to define the name by which the local LU is 
known throughout the network. To use it for this purpose, the 
verb should be issued prior to the local LU f s participation in any 
network activity, such as initializing (LU,mode) session limits. 

2. The LU-LU session limit is the maximum number of sessions that the 
local LU can have active at a time. It represents the upper bound 
on the sum of the (LU,mode) session limits, and it must be equal 
to or greater than the sum of the (LU,mode) session limits cur¬ 
rently in effect; see the description of the return code, 
LU_SESS10N_LIMIT_EXCEEDED, in "Return Codes" on page 5-51 for 
more detaiIs. 

3. If no LU-LU session limit is defined at the local LU, the upper 
bound, if any, on the sum of the (LU,mode) session limits is 
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product-determined. For example* the upper bound may be a fixed 
value or determined by an algorithm. 

4. When the first user ID and associated password and profiles are 
added* the LU’s conversation-level security verification list is 
created. When the last user ID and associated password and pro¬ 
files are deleted* the conversation-level security verification 
list itself is deleted. 

5. The local LU uses the conversation-level security verification 
list to verify the access security information on allocation 
requests it receives. Specifically* when the LU receives an allo¬ 
cation request carrying a user ID and password* it verifies that 
the user ID and password are present in its conversation-level 
security verification list. If the allocation request also car¬ 
ries a profile* the LU verifies that the profile is also present 
in the list. Allocation requests that carry no access security 
information* or that carry a user ID and an already-verified indi¬ 
cation (and may also carry a profile)* are not verified against 
the conversation-level security verification list. However* 
these requests may be subject to resource-access verification* as 
determined by the SECURITY..ACCESS parameter on DEFINE_TP. 

6. If the conversation-level security verification list does not 
exist* the local LU will perform no conversation-level security 
verification. Allocation requests that carry a user ID and pass¬ 
word will not be accepted. 

7. If no map names are defined at the local LU* it will perform no 
data mapping. 

8. More details concerning the LU f s use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manual; 
Architecture Logic for LU Type 6.2 . 
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DEFINE.REMOTE LU 


Initializes or changes parameters that control the operation of the 
local LU in conjunction with a remote LU. 



Supplied Parameters: 

DEFXNE_REMOTE_LU 

FULLY_QUALIFIED_LU_NAME C variable ) 


[ LOCALLY KNOWN LU NAME ( NONE ) 1 

( NAME ( variable ) ) J 


[ UNINTERPRETED LU NAME ( NONE ) 1 

1 ( name ( variable 1 ) I 


f INITIATE TYPE ( INITIATE ONLY ) 1 

[ C INITIAT E_0R_QUEUE ) I 


[ PARALLEL SESSION.SUPPORT C YES 1 1 
[ ( NO ) J 


| CNOS SUPPORT ( YES ) 1 
[ f NO ) J 


[ LU_LU PASSWORD ( NONE ) 1 

[ ( VALUE ( variable ) ) j 


[ ( NONE ) 1 

SECURITY.ACCEPTANCE ( CONVERSATION ) 

[ ( ALREADY.VERIFIED ) j 


Returned Parameters: 


return.code ( variable ) 


• 

# 


Supplied Parameters: 


FULLYJ}UALIFIED_LU_NAME specifies the fully qualified name of the 
remote LU. If the specified name is currently undefined to the local 
LU# this verb defines the remote LU’s fully qualified name and ini¬ 
tializes the other parameter values specified on this verb. If the 
specified name is already defined to the local LU# this verb changes 
the other parameter values. 

LOCALLY_KNOWN_LU_NAME specifies the locally-known name of the remote 
LU that local transaction programs can specify on the LU_NAME parame¬ 
ter of the MCJULOCATE and ALLOCATE verbs. 

• NONE specifies that no locally-known LU name i s to be defined. 

• NAME specifies the locally-known LU name of the remote LU. This 
name is not sent outside the local LU. 

UNINTERPRETED_LU_NAME specifies the uninterpreted LU name of the 
remote LU# which the local LU uses on INITIATE and TERMINATE requests 
it sends to its SSCP. 

• NONE specifies that no uni nterpreted LU name is to be defined. 

• NAME specifies the uninterpreted LU name of the remote LU. 
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INITIATE_TYPE specifies the session-initiation type that the local LU 
is to use on INITIATE requests it sends to its SSCP for initiating 
sessions with the remote LU. 

• INITIA7E_0NLY specifies that session initiation requests are to 
indicate "initiate only." The SSCP will not queue the session 
initiation requests. 

• INITIATE_OR_QUEUE specifies that session initiation requests are 
to indicate "initiate or queue." The SSCP may queue session the 
initiation requests# if necessary# while waiting for the remote 
LU to become available. 

PARALLEL_SESSION_SUPPQRT specifies whether the local LU supports par¬ 
allel sessions with the remote LU. The local LU uses this parameter 
to determine the indication for parallel session support that it spec¬ 
ifies in session activation (BIND) requests and responses. 

• YES specifies that parallel sessions are supported. 

• NO specifies that parallel sessions are not supported. 

CNOS_SUPPORT specifies whether the local LU supports the exchange of 
CNOS requests and replies with the remote LU. The local LU uses this 
parameter to determine the indication for CNOS support that it speci¬ 
fies in session activation (BIND) requests and responses. 

• YES specifies that CNOS is supported. PARAL- 
LEL_$ES$ION_SUPPORT(YES) must also be specified. 

• NO specifies that CNOS is not supported. PARAL- 
LEL_SESSION_SUPPORT(NO) must also be specified. 

LU_LU_PASSWORD specifies the LU-LU password to be used for 
session-level LU-LU verification during session activation. The 
LU-LU password must be the same as that defined at the remote LU. 

• NONE specifies that no LU-LU password i s to be defined. 

• NAME specifies the LU-LU password. It must be a random binary 
value up to 64 bits (8 bytes) in length. It should be specified 
in a form that can yield any binary value. For example# it could 
be specified using the hexadecimal digits 0# 1# 2# ...# E# F to 
represent each group of 4 bits. After being defined# the LU-LU 
password is nondisplayable. 

SECURITY..ACCEPTANCE specifies the level of access security informa¬ 
tion that the local LU will accept on allocation requests it receives 
from the remote LU. Access security information that includes a pass¬ 
word is verified against the LU’s conversation-level security verifi¬ 
cation list prior to acceptance# as described for the SECURITY 
parameter on the DEFINE_LOCAL_LU verb. 

• NONE specifies that no access security information is to be 
accepted on allocation requests received from the remote LU. 

• CONVERSATION specifies that the local LU will accept 
conversation-level access security information# which must 
include both a user ID and password# and may also include a pro¬ 
file. The local LU will not accept allocation requests that 
include the already-verified indication. 

• ALREADY_VERIFIED specifies that the local LU will accept 
conversation-level access security information# which may include 
the already-verified indication in place of a password. 

Returned Parameters: 

RETURN_CODE returns an indication of the result of verb execution. 

• OK 

• PARAMETER_ERROR (for one of the following reasons) 

FULLY_QUALIFIED_LU_NAME specifies a value that is not a 
type-A symbol string. 
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DEFXNE_REMOTEJ.ll 


PARALLEL_SESSION_SUPPORT(YES) is specified and the total 
LU-LU session limit is 1. 

PARALLEL_SESSION_$UPPORT(YES) and CN0S_SUPP0RTED(N0) are 
specified* 

PARALLEL_SESSION_SUPPORT(NO) and CNOS_SUPPORTED(YE$) are 
specified. 

PARALLEL SESSIQN_SUPPORT* CNOS_SUPPQRT, LU_LU_PASSWORD* or 
SECURITY_ACCEPTANCE is specified and at least one (LU,mode) 
session limit for the remote LU is not zero* or the LU-LU ses¬ 
sion count between the local and remote LUs is not zero. 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have define privilege. 
Notes: 

1. This verb can be used to define the fully qualified name of a 
remote LU. In this case* the verb should be issued prior to the 
local LU participating in any network activity involving the 
remote LU. 

2. If no locally-known name of the remote LU is defined at the local 
LU* local transaction programs may specify the remote LU f s fully 
qualified LU name* or its uninterpreted name if one is currently 
defined at the local LU* on the LU_NAME parameter of the 
MCJULOCATE and ALLOCATE verbs. 

3. An uninterpreted name of the remote-LU must be defined at both the 
local LU and its S5CP before the local LU sends INITIATE and TER¬ 
MINATE requests to its SSCP. 

4. If no initiate type is defined at the local LU for the remote LU 
and the product LU sends INITIATE requests to its SSCP* the type 
used on the requests is product-determined. 

5. Parallel-session support must be defined at the local LU for the 
remote LU before it activates sessions with the remote LU. 

6. CNOS support must be defined at the local LU for the remote LU 
before it activates sessions with the remote LU. 

7. Session-level LU-LU verification is used to verify the identity 
of each LU to its session partner LU during activation of an LU-LU 
session. It uses an LU-LU password as the key to the Data 
Encryption Standard (DES) algorithm* in conjunction with an 
LU-generated random-data value carried on the session-activation 
request and response. 

The same LU-LU password specification must be defined at both LUs* 
either NONE or an LU-LU password. An LU-LU password should be a 
random binary value* The means for specifying the LU-LU password 
is product-dependent. The product may provide a utility proce¬ 
dure for generating an LU-LU password* or it may require the user 
to enter the password manually. In the latter case* the human 
operator may use the following method to produce a random value: 

• Enter the password value by means of hex digits (the numerals 
0 through 9 and the upper-case characters A through F). 

• Enter 16 random hex digits (fewer digits or non-random digits 
will reduce the effective security for LU-LU verification). 

• For each of the 16 hex digits* flip a coin four times* At 
each flip of the coin* follow the path illustrated in the fol¬ 
lowing figure. The fourth flip will select the hex digit to 
be used* Repeat this procedure until all 16 hex digits are 
obtained. The result is a 64-bit random LU-LU password. 
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start 


"heads" to the left 

r- 

vi 


1st flip -> 
2nd flip -> 


"tails" to the right 
iv 


3rd flip —> 

4th flii 

finish -> 0 i 2 3 4 5 6 7 8 9 A B C D E F <- hex digit 




The total number of coin flips is 64. Of course, the equivalent 
value for the LU-LU password can be obtained in binary notation* 
where each coin flip* of "heads" or "tails*" selects the next 
binary digit* 0 or 1* respectively. 

8. If no LU-LU password is defined at the local LU for the remote LU* 
no session-level LU-LU verification will take place between the 
two LUs. 

9. Conversation-level access security information is carried on 
allocation requests in order for the receiving LU to verify the 
identity of the user ID, and to control access to its resources. 
The information includes a user ID together with a password or the 
already-verified indication* the information may also include a 
profile. Allocation requests that include a password are veri¬ 
fied against the LU f s conversation-level security verification 
list* see the SECURITY parameter on the DEFINE_LOCAL_LU verb for 
more details about conversation-level security verification. The 
already-verified indication signifies that the identity of the 
user ID has already been verified. 

10. If no conversation-level security is defined at the local LU for 
the remote LU* the local LU will accept from the remote LU only 
allocation requests that carry no access security information. 

11. More details concerning the LU f s use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manual; 
Architecture Logic for LU Type 6.2 . 
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DEFXNE.MODE 


Initializes or changes parameters that control the operation of the 
local LU in conjunction with a group of sessions to the specified 
remote LU* the session group being identified by a mode name. 


DEFINE NODE 


Supplied Parameters: 

FULLY_QUALIFIED_LU_NANE C variable ) 

NODE.NANE ( variable ) 

[ s end_pacing_wIndou C variable ) ] 

[ receive_pacing_windou ( variable ) ] 

[ SEND_MAX_RU_SXZE_LOMER_B0UND ( variable ) ] 

[ SEND_HAX_RU_SIZE_UPPER_BOUND ( variable ) ] 

[ RECEIVE_MAX_RU_SIZE_LOUER_BOUND ( variable ) ] 

[ RECEIVE_MAX_RU_SIZE_UPPER_BOUND C variable ) J 


SYNC_LEVEL_SUPPORT C CONFIRM ) 

C CONFXRN.SYNCPT ) 


( OPERATOR ) 

SINGLE SESSXON.REXNXTXATXON ( PLU ) 

( SLU ) 

( PLU OR SLU ) 


SESSXON_LEVEL_CRYPTOGRAPHY ( NO ) 

C YES ) 


[ CONUINNER_AUTO_ACTIVATEJ.IMIT ( variable ) ] 


Returned Parameters: 
RETURN CODE ( variable ) 


Supplied Parameters: 

FULLY_QUAL1FIED_LU_NAME specifies the fully qualified name of the 
remote LU to which the other parameters of this verb apply* 

MQDE_NAME specifies the mode name for the group of sessions to which 
the remaining parameters of this verb apply. If the specified name is 
currently undefined at the local LU for the remote LU, this verb 
defines the mode name and initializes the other parameter values spec¬ 
ified on this verb. If the specified name is already defined at the 
local LU for the remote LU, this verb changes the other parameter val¬ 
ues. 

SEND_PACING_WXNDOU specifies the pacing window size to be used on the 
sessions for normal-flow requests that the local LU sends. The local 
LU uses this parameter to determine the values for its send window 
size and the remote LU f s receive window size that it specifies in ses¬ 
sion activation (BIND) requests. 
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RECEXVE_PACXNG_I4XND0U specifies the pacing window size to be used on 
the sessions for normal-flow requests that the local LU receives. The 
local LU uses this parameter to determine the values for its receive 
window size and the remote LU v s send window size that it specifies in 
session activation (BIND) requests and responses. 

SEND_MAX_RU_SIZE_LOWER_BQUND specifies the lower bound for the maxi¬ 
mum size of normal-flow requests that the local LU sends on the ses¬ 
sions. This value must be less than or equal to the value specified 
on SEND_MAX_RU_$IZE_UPPER_BOUND. The local LU uses these lower- and 
upper-bound values to determine the value for its send maximum RU size 
that it specifies in session activation (BIND) requests and 
responses. 

SENDJ1AXJIU_SIZE_UPPER_B0UND specifies the upper bound for the maxi¬ 
mum size of normal-flow requests that the local LU sends. 

RECEIVE J1AXJHJ_SIZE_L0UER_B0UND specifies the lower bound for the 
maximum size of normal-flow requests that the local LU receives on the 
sessions. This value must be less than or equal to the value speci¬ 
fied on RECEIVE_MAX_RU_SIZE_UPPER_BQUND. The local LU uses these 
lower- and upper-bound values to determine the value for its receive 
maximum RU size that it specifies in session activation (BIND) 
requests and responses. 

RECEIVE_MAX_RU_SXZE_l)PPER_BOUND specifies the upper bound for the 
maximum size of normal-flow requests that the local LU receives. 

SYNC_LEVEL_SUPPORT specifies the synchronization levels that the 
local LU supports for conversations allocated to the sessions. The 
local LU uses this parameter to determine the indication for the syn¬ 
chronization level that it specifies in session activation (BIND) 
requests and responses. 

• CONFIRM specifies that conversations may use a synchronization 
level of NONE or CONFIRM. 

• CONFIRM_SYNCPT specifies that conversations may use a synchroni¬ 
zation level of NONE, CONFIRM, or SYNCPT. 

SINGLE_SESSXON_REINITXATXON specifies the responsibility for session 
reinitiation of a single session with the remote LU. The local LU 
uses this parameter to determine the indication for session reiniti¬ 
ation responsibility that it specifies in session activation (BIND) 
requests and responses. The remote LU must be defined to not support 
parallel sessions (see the PARALLEL_SESSION_SUPPORT parameter on the 
DEFINE_REMOTE_LU verb). 

• OPERATOR specifies that neither LU will automatically attempt to 
reinitiate the session. If a reinitiation race occurs, where the 
operators at both LUs attempt to reinitiate the session at the 
same time, the reinitiation is successfully completed by the LU 
with the greater fully qualified LU name (provided no session 
activation errors are encountered).. The comparison of the fully 
qualified LU names is based on their hexadecimal values. 

• PLU specifies that the primary LU will automatically attempt to 
reinitiate the session. 

• SLU specifies that the secondary LU will automatically attempt to 
reinitiate the session. 

• PLU_OR_SLU specifies that either LU may automatically attempt to 
reinitiate the session. A reinitiation race between the two LUs 
is resolved in the same way as for operator reinitiation. 

SESSIGN_LEVELJ)RYPTOGRAPHY specifies whether the local LU supports 
session-level cryptography for the sessions. The local LU uses this 
parameter to determine the indication for cryptography support that 
it specifies in session activation (BIND) requests and responses. 

• NONE specifies that no session-level cryptography i s to be used. 
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• MANDATORY specifies that session-level mandatory cryptography is 
to be used on all FMD requests flowing on the sessions. 

CONI4X NNER_AUT 0_ACT I VAT E_L IMIT specifies the automatic-activation 
limit on the number of contention-winner sessions that the local LU 
can automatically activate when the minimum number of contention- 
winner sessions for the local LU increases (as a result of CNOS proc¬ 
essing). The actual limit on the number of contention-winner sessions 
automatically activated is the lesser of the value specified on this 
parameter and the new minimum number of contention-winner sessions 
for the local LU. 

A value of 0 specifies that the local LU i s to automatically activate 
no sessions. 

Returned Parameters: 

RETURNjCODE returns an indication of the result of verb execution. 

• OK 

• PARAMETER_ERROR (for one of the following reasons) 

FULLY_QUALIFIED_LU_NAME does not specify a remote LU name 
defined at the local LU. 

FUL LY_QUA LI FIED_L U_NAME specifies a value that is not a 
type-A symbol string. 

— M0DE_NAME specifies a value that is not a type-A symbol 
string. 

SEND MAX_RU_$IZE LOWER_BOUND specifies a value exceeding that 
on SEND_MAX_RU_SfZE_UPPER_BOUND. 

RECEIVE_MAX_RU_SIZE_LQWER_BOUND specifies a value exceeding 
that on RECEIVE_MAX_RU_SIZE_UPPER BOUND. 

SINGLE_SESSION_REINITIATION is specified for a remote LU that 
is currently defined as supporting parallel sessions. 

A parameter other than CONWINNER_AUTO_ACTIVATEJ.IMIT is spec¬ 
ified and the (LU,mode) session limit and count for the mode 
name are not zero. 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have define privilege. 
Notes; 

1. If the mode name is currently defined, the (LU,mode) session limit 
and count must be zero when this verb is issued specifying any of 
the parameters other than CQNWINNER_AUTO_ACTIVATE_LIMIT. The 
auto-activation limit on the number of contention-winner sessions 
may be initialized or changed at anytime. 

2. If no send or receive pacing window size is defined, a 

product-determined window size is used. 

3. If no lower bound is defined for the send or receive maximum size 

of normal-flow requests, a product-determined lower bound is 

used. 

4. If no upper bound is defined for the send or receive maximum size 

of normal-flow requests, a product-determined upper bound is 

used. 

5. If no synchronization level support is defined for the mode name, 
conversations may use NONE or CONFIRM. 

6. If no responsibility for session reinitiation of a single session 
is defined for the mode name, a product-determined responsibility 
is used. 

7. If no session-level cryptography is defined for the mode name, 

none i s used. 
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8. If no automatic-activation limit for contention-winner sessions 
is defined for the mode name* the local LU may not automatically 
activate any sessions, or it may automatically activate sessions 
up to the minimum number of the LU v s contention-winner sessions 
currently in effect, depending on the product. 

9. More details concerning the LU's use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manual: 
Architecture Logic for LU Type 6.2 . 
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Initializes or changes parameters that control the operation of the 
local LU in conjunction with a transaction program. 


DEFINE TP 


Supplied Parameters; 
TP_NAME ( variable ) 


( ENABLED ) 

STATUS ( TEMP DISABLED ) 
( PERM.DISABLED ) 


[ CONVERSATION.TYPE ( MAPPED | BASIC ) ] 

[ SYNC.LEVEL ( NONE | CONFIRM | SYNCPT ) ] 


SECURITY_REQUIRED ( 


t 


C NONE ) 

( CONVERSATION ) 

( PROFILE ) ) 

( ACCESS ( USER.ID ) ) 

C USER_ID_PROFILE ) ) 


( ADD C USER.ID ( variable ) 
security.access profile ( variable ) ) ) 

( delete ( user.id ( variable ) 

PROFILE ( variable J ) J 


PIP ( NO ) 

( YES ( variable 


DATA.MAPPIN6 




FMH.DATA 


C NO ) 1 

C YES ) J 

C NO ) 1 

( YES ) J 


( NONE ) 

PRIVILEGE ( CNOS j SESSION.CONTROL | DEFINE | DISPLAY | 
ALLOCATE.SERVICE.TP ) 


Returned Parameters: 

[ RETURN.CODE ( variable ) ] 


Supplied Parameters: 

TP_NAHE specifies the local transaction program name. If the speci¬ 
fied name is not currently defined at the local LU> this verb defines 
the program name and initializes the other parameter values specified 
on this verb. If the specified name is already defined to the local 
LU» this verb changes the other parameter values. 

STATUS specifies the status for starting execution of the transaction 
program uhen the local LU receives an allocation request naming the 
program. 

• ENABLED specifies that the local LU can start the program. 
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• TEMP_DXSABLED specifies that the local LU cannot start the pro¬ 
gram. The local LU rejects the allocation request with an indi¬ 
cation that the program is not available but retry is possible. 

• PERM_DISABLED specifies that the local LU cannot start the pro¬ 
gram. The local LU rejects the allocation request with an indi¬ 
cation that the program is not available and no retry is possible. 

CONVERSATION_TYPE specifies the conversation type allowed on allo¬ 
cation requests that start the transaction program. 

• MAPPED specifies that allocation requests indicating mapped con¬ 
versation are allowed to start the program. 

• BASIC specifies that allocation requests indicating basic conver¬ 
sation are allowed to start the program. 

One or both of these arguments may be specified. 

SYNC_LEVEL specifies the synchronization level allowed on allocation 
requests that start the transaction program. 

• NONE specifies that allocation requests indicating a synchroniza¬ 
tion level of none are allowed to start the program. 

• CONFIRM specifies that allocation requests indicating a synchro¬ 
nization level of confirm are allowed to start the program. 

• SYNCPT specifies that allocation requests indicating a synchroni¬ 
zation level of sync point are allowed to start the program. 

Any combination of these arguments may be specified. 

SECURXTYJREQUXRED specifies the type of security verification 
required to be performed on incoming allocation requests that desig¬ 
nate the transaction program. (Conversation-level security verifica¬ 
tion* when required* is performed as specified on the SECURITY 
parameter of the DEFINE_LOCAL_LU verb.) 

• NONE specifies that no verification is required. Allocation 
requests designating the transaction program may omit or include 
access security information. Conversation-level security verifi- 
cation will be performed on those requests that include a user ID 
and password* but no resource-access verification is performed. 

• CONVERSATION specifies that conversation-level security verifica¬ 
tion is to be performed on requests that carry a user ID and pass¬ 
word* but no resource-access verification is performed. 
Allocation requests designating the transaction program must car¬ 
ry a user ID and either a password or an already-verified indi¬ 
cation. (Acceptance of the already-verified indication is 
determined by the SECURITY ACCEPTANCE parameter of the 
DEFINE_REMOTE_LU verb.) 

• ACCESS specifies that conversation-level security verification is 
to be performed on requests that carry a user ID and password* and 
resource-access verification is also to be performed. Allocation 
requests designating the transaction program must carry a user ID 
and either a password or an already-verified indication. (Ac¬ 
ceptance of the already-verified indication is determined by the 
SECURITY_ACCEPTANCE parameter of the DEFINE_REMOTE_LU verb.) The 
local LU performs resource-access verification using a 
resource-access authorization list associated with the trans¬ 
action program. The list is created by means of the SECURI- 
TY^ACCESS parameter. The type of resource-access verification to 
be performed is specified as follows: 

— PROFILE specifies that the profile carried on the allocation 
request is to be verified against the resource-access author¬ 
ization list. The allocation request must carry a profile 
that matches one in the authorization list. The user ID on 
the allocation request is ignored for the resource-access 
verification. 
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— USER_ID specifies that the user ID carried on the allocation 
request is to be verified against the resource-access author¬ 
ization list. The allocation request must carry a user ID 
that matches one in the authorization list. The profile (if 
present) on the allocation request is ignored for the 
resource-access verification. 

— USER_XD_PROFILE specifies that the user ID and profile car¬ 
ried on the allocation request are to be verified against the 
resource-access authorization list. The allocation request 
must carry a user ID and profile that match a user ID and 
associated profile in the authorization list. 

SECURITY_ACCESS specifies to add or delete access security informa¬ 
tion that the local LU uses for resource-access verification. This 
parameter must be specified when the SECURITY_REQUIRED parameter 
specifies that resource-access verification is required. The local 
LU updates a resource-access authorization list, associated with the 
transaction program, from the information supplied on this parameter. 
The resource-access authorization list consists of either (1) one or 
more profiles, or (2) one or more user IDs with zero or more profiles 
associated with each user ID. 

• ADD specifies to add access security information to the 
resource-access authorization list associated with the trans¬ 
action program. A profile may be specified alone, or a user ID 
may be specified alone or together with a profile. 

- USER_ID specifies a user ID. A user ID must be specified when 
the SECURITY_REQUIRED parameter specifies resource-access 
verification that includes verification of user IDs. A pro¬ 
file may also be specified, depending on the 5ECURI- 
TY_REQUIRED parameter. If the user ID is not currently 
defined for the transaction program, the LU adds it and the 
profile (if specified) to the resource-access authorization 
list. If the user ID is already defined, the list is updated 
with the profile. 

- PROFILE specifies a profile to be added to the 
resource-access authorization list. A profile may be speci¬ 
fied only when the SECURITY_REQUIRED parameter specifies 
resource-access verification that includes verification of 
profiles. A profile must be specified alone when the 
resource-access verification includes verification of only 
profiles. A user ID must also be specified when the 
resource-access verification includes verification of both 
user IDs and profiles. If a user ID is also specified, the 
profile is added to those associated with the user ID. 

• DELETE specifies to delete access security information from the 
resource-access authorization list associated with the trans¬ 
action program. A profile may be specified alone, or a user ID 
may be specified alone or together with a profile. 

- USER_ID specifies a user ID. A user ID must be specified when 
the SECURITY_REQUIRED parameter specifies resource-access 
verification that includes verification of user IDs. A pro¬ 
file may also be specified, depending on the SECURI- 
TY_REQUIRED parameter. If a user ID is specified alone, the 
user ID and all of its associated profiles are deleted from 
the resource-access authorization list. If a profile is also 
specified, the user ID and profile are deleted when no other 
profiles are currently defined for the user ID; if other pro¬ 
files are currently defined for the user ID, the user ID and 
other profiles remain defined. 

— PROFILE specifies a profile to be deleted from the 
resource-access authorization list. A profile may be speci¬ 
fied only when the $ECURITY_REQUIRED parameter specifies 
resource-access verification that includes verification of 
profiles. A profile must be specified alone when the 
resource-access verification includes verification of only 
profiles. A user ID must also be specified when the SECURI- 
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TY_REQUIRED parameter specifies resource-access verification 
that includes verification of both user IDs and profiles. 

PZP specifies whether PIP data is required on allocation requests that 
start the transaction program. 

• NO specifies that no PIP data is required. Only allocation 
requests carrying no PIP data are allowed to start the program. 

• YES specifies that PIP data is required. Only allocation requests 
carrying the number of PIP subfields specified on this parameter 
are allowed to start the program. The specified number should 
agree with the number of PIP variables associated with the pro¬ 
gram. For more information about the association of PIP variables 
with the program* see "Transaction Program Structure and Exe¬ 
cution" in Chapter 3. 

DATA_MAPPING specifies whether data mapping support i s to be provided 
to the transaction program. This parameter applies only when CONVER- 
SATION_TYPE(MAPPED) or CONVERSATION_TYPE(MAPPED|BASIC) is also speci- 
f i ed. 

• NO specifies that no data mapping support is to be provided. Map 
names received on any mapped conversations allocated to the pro¬ 
gram are rejected. 

• YES specifies that data mapping support is to be provided. 

FMH_DATA specifies whether FMH data support is to be provided to the 
transaction program. This parameter applies only when CONVERSA- 
TI0N_TYPE(MAPPED) or CONVERSATION_TYPE(MAPPED|BASIC) is also speci¬ 
fied. 

• NO specifies that no FMH data support i s to be provided. FMH data 
received on any mapped conversations allocated to the program is 
rejected. 

• YES specifies that FMH data support i s to be provided. 

PRIVILEGE specifies the category of control operator verbs that the 
transaction program is allowed to issue. Either NONE or any combina¬ 
tion of CNOS * SESSI0N_C0NTR0L * DEFINE, DISPLAY, and ALLO- 
CATE_SERVICE_TP may be specified. 

• NONE specifies that the program is not allowed to issue verbs that 
require a privilege to do so. 

• CNOS specifies that the program is allowed to issue the CNOS 
verbs. 

• SESSION_CONTROL specifies that the program is allowed to issue 
the ACTIVATE_SESSION and DEACTIVATE_SESSION verbs. 

• DEFINE specifies that the program is allowed to issue the DEFINE 
verbs and the DELETE verbs. 

• DISPLAY specifies that the program is allowed to issue the DISPLAY 
verbs. 

• ALLOCATE_SERVICE_TP specifies that the program is allowed to 
issue the ALLOCATE verb with its TPN parameter specifying an SNA 
service transaction program. 

Returned Parameters; 

RETURN_CODE returns an indication of the result of verb execution. 

• OK 

• PARAMETER_ERROR (for one of the following reasons) 

CONVERSATI0N_TYPE(BASIC) and either DATA_MAPPING(YES) or 
FMH_DATA<YES) are specified. 

SECURITY_ACCESS is specified, SECURITY.REQUIRED is omitted, 
and no type of security verification is currently defined. 
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— SECURITY_ACCESS is specified and the type of security verifi¬ 
cation specified on SECURITY_REQUIRED or currently defined 
does not include resource-access verification. 

— SECURITY_ACCESS specifies a user ID or profile and the type of 
security verification specified on SECURITY_REQUIRED or cur¬ 
rently defined does not include the respective verification 
of user IDs or profiles. 

— SECURITY_ACCESS specifies only a profile and the type of 
security verification specified on SECURITY^REQUIRED or cur¬ 
rently defined includes verification of user IDs. 
SECURITY_ACCESS(ADD(...)) specifies a user ID or profile that 
is not a symbol-string type (A* AE* GR* or DB) that the prod¬ 
uct supports. 

SECURITY^ACCESSCDELETEC... )) specifies a user ID dr profile 
that is not currently defined at the local LU. 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have define privilege. 

Notes; 

1. The values specified on the parameters of this verb take effect at 
the next invocation of the transaction program. 

2. If the status for starting execution of the transaction program is 
not defined* the program's status is ENABLED. 

3. If the conversation type allowed on allocation requests that 
start the transaction program is not defined* a mapped or basic 
conversation is allowed. 

4. If the synchronization level allowed on allocation requests that 
start the transaction program is not defined* a synchronization 
level of NONE or CONFIRM is allowed. 

5. Resource-access verification is used to verify the access securi¬ 
ty information on incoming allocation requests for the authority 
to access the transaction program named on the requests and the 
local resources that the program allocates. The local LU main¬ 
tains a resource-access authorization list for this purpose. The 
authorization list is created and updated from information sup¬ 
plied on the SECURITY_ACCESS parameter. The list may consist of 
profiles alone* or it may consist of user IDs alone or with asso¬ 
ciated profiles* as determined by the SECURITY_REQUIRED parame¬ 
ter. 

6. There is a resource-access authorization list for each trans¬ 
action program for which resource-access verification is defined. 
When the first user ID and associated password and profiles are 
added* or the first profile is added* a resource-access authori¬ 
zation list is created for the program. When the last user ID and 
associated password and profiles are deleted* or the last profile 
is deleted* the resource-access authorization list itself is 
deleted. 

7. If resource-access verification is to be performed and it 
includes verification of user IDs, the authorization list must 
contain one or more user IDs when the verification of allocation 
requests takes place. Similarly* if the verification includes 
profiles* the list must contain one or more profiles. 

8. If the type of security verification required on incoming allo¬ 
cation requests is currently defined and a different type is spec¬ 
ified* the new type replaces the current type. If resource-access 
verification is currently defined as being required and a differ¬ 
ent type of resource-access verification is specified* the 
resource-access authori zati on list is deleted and a new list is 
created. 
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9. If SECURITY_ACCESS is specified without SECURITY_REQUIRED, the 
type of security verification currently defined applies to the 
use of the SECURITY_ACCESS parameter. 

10. If no type of security verification is currently defined* none is 
required to start the program. However* if the allocation request 
carries access security information* the local LU performs 
conversation-level security verification. 

11. If no PIP subfield number is defined at the local LU for the 
transaction program* only allocation requests carrying no PIP 
data are allowed to start the program. 

12. If no data mapping support is defined at the local LU for the 
transaction program* none is provided. 

13. If no FMH data support is defined at the local LU for the trans¬ 
action program* none is provided. 

14. If no privilege is defined at the local LU for the transaction 
program* the program may issue only conversation verbs. 

15. More details concerning the LU f s use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manual; 
Architecture logic for LU Type 6.2 . 
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Returns current values of parameters that control the operation of the 
local LU. 


DX S PLAY_LOCAL_LU 

Supplied Parameters: 

FULLY_QUALIFIED_LU_NAME ( variable 1 


Returned Parameters: 


RETURN.CODE ( variable ) 


[ LU_SESSXON_LXMXT ( variable ) ] 


[ LU_SESSXON_COUNT ( variable ) ] 


[ SECURITY ( variable ) ] 


[ NAP_NAMES C variable ) ] 


[ REMOTE_LU_NAMES ( variable ) J 


[ TP_NAMES ( variable ) ] 


• 

t 


supplied Parameters? 

FULLY_QUALIFIED_LU_NAME specifies the fully qualified name of the 
local LU. 

Returned Parameters: 

RETURN_CODE returns an indication of the result of verb execution. 

• OK 

• PARAMETER ERROR (for the following reason) 

FULLY_QUALIFIED_LU_NAME does not specify a local LU name cur¬ 
rently defined at the local LU. 

LU_SESSXON_LXMXT returns the LU-LU session limit currently defined at 
the local LU. 

LU_SESSXON_COUNT returns the LU-LU session count* which is the total 
number of active sessions for the local LU. 

SECURITY returns the conversation-level security verification list 
currently defined at the local LU. 

MAP_NAMES returns a list of the local map names currently defined at 
the local LU. 

REMOTE_LU_NAMES returns a list of the remote LU names currently 
defined at the local LU. 

TP_NAMES returns a list of the local transaction program names cur¬ 
rently defined at the local LU. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have display privilege. 
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Notes? 

1. This verb can be used to obtain operating parameter values that 
are established by the DEFINE_LOCAL_LU> DEFINE_REMOTE_LU, and 
DEFINE_TP verbs* as well as the current LU-LU session count. 

2. More details concerning the LU T s use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manual: 
Architecture logic for IU Tvpq 6.2 . 
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DISPLAY_REMOTE_LU 


Returns current values of parameters that control the operation of the 
local LU in conjunction with a remote LU. 


DISPLAY_REMOTE_LU 

Supplied Parameters: 

FULLY_QUALIFIED_LU_NAME C variable ) 


Returned Parameters: 


RETURN.CODE ( variable ) 


[ LOCALLY_KNOUN_LU_NAME C variable ) ] 


[ UNINTERPRETED_LU_NAME ( variable ) ] 


[ INITIATE_TYPE C variable ) ] 


[ PARALLEL_SESSION_SUPPORT ( variable ) ] 


[ cnos_support C variable ) J 


[ SECURXTY_ACCEPTANCE_LOCAL_LU C variable ) ] 


[ SECURITY_ACCEPTANCE_REMOTE_LU C variable 1 ] 


[ MODE_NAMES ( variable ) ] 


• 

* 


Supplied Parameters: 

FULLYJ*UALIFIED_LU_NAME specifies the fully qualified name of the 
remote LU. 

Returned Parameters: 

RETURN_CODE returns an indication of the result of verb execution* 

• OK 

• PARAMETER_ERROR (for the following reason) 

FULLY_QUALIFIED_LU_NAME does not specify a remote LU name 
currently defined at the local LU. 

LOCALLY_KNOMN_LU_NAME returns the locally-known name of the remote 
LU, currently defined at the local LU. 

UNINTERPRETED_LU_NAME returns the uninterpreted name of the remote 
LU, currently defined at the local LU. 

INITIATE_TYPE returns an indication of the session-initiation type 
for the remote LU, currently defined at the local LU. 

PARALLEL_SESSION_SUPPORT returns an indication of the parallel ses¬ 
sion support for sessions with the remote LU. If one or more sessions 
are active between the local and remote LUs, this parameter returns an 
indication of the actual parallel session support; otherwise, it 
returns an indication of the support currently defined at the local 
LU. 

CNOS_SUPPORT returns an indication of the CNOS support for sessions 
with the remote LU. If one or more sessions are active between the 
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local and remote LUs* this parameter returns an indication of the 
actual CNOS support; otherwise* it returns an indication of the sup¬ 
port currently defined at the local LU, 

SECURITYJ\CCEPTANCE_LOCAL_LU returns an indication of the level of 
access security information that the local LU will accept on allo¬ 
cation requests it receives from the remote LU* currently defined at 
the local LU. 

S ECUR X TY_ACCEPTANC E_REHOTE_LU returns an indication of the level of 
access security information that the remote LU will accept on allo¬ 
cation requests it receives from the local LU* when one or more ses¬ 
sions are active between the local and remote LUs. The value returned 
is what is currently defined at the remote LU* which is conveyed to 
the local LU during session activation. 

MODE_NAMES returns a list of the mode names currently defined at the 
local LU for sessions with the remote LU. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have display privilege. 

Notes: 

1. This verb is used to obtain operating parameter values that are 
defined by the DEFINE_REMOTE_LU and DEFINEJ10DE verbs. 

2. More details concerning the LU T s use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manual: 
Architecture Logic.for LU Type 6.2 . 
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DISPLAY NODE 


Returns current values of parameters that control the operation of the 
local LU in conjunction with a group of sessions to a remote LU> the 
session group being identified by a mode name. 


DXSPLAYNODE 


i 


Supplied Parameters: 

FULLY_QUALIFXED_LU_NAME ( Variable ) 

MODE_NAME ( variable ) 

Returned Parameters: 

RETURN_C0DE ( variable ) 

[ s end_paci NG_uxNDOM ( variable ) ] 

[ RECEXVE_PACXNG_HXNDOU C variable ) ] 

[ SEMD_HAX_RU_SXZE_LOMER_BOUND C variable ) ] 

[ SEND_MAX_RU_SIZE_UPPER_BOUND ( variable ) ] 

[ RECEIVE_MAX_RU_SXZE_LOWER_BOUND C variable ) ] 

[ RECEIVE_MAX_RU_SIZE_UPPER_BOUND ( variable ) ] 

[ SYNC_LEVEL_SUPPORT ( variable ) ] 

[ SXNGLE.SESSXON.REXNXTXATXON ( Variable ) ] 

[ SESSXON_LEVEL_CRYPTOGRAPHY C variable ) ] 

[ CONMINNER_AUTO_ACTXVATE_LIHIT I variable ) ] 

[ lu_mode_session_limit ( variable I ] 

[ HXN.CONUXNNERS ( variable ) ] 

[ MXN.CONLOSERS ( variable ) ] 

[ termimation_count c variable ) ] 

[ DRAXN_LOCAL_LU C variable ) ] 

[ DRAXN_REMOTE_LU C variable ) ] 

[ LU_MODE_SESSXON_COUNT [ variable ) ] 

[ conuxnners_sess x on_count ( variable ) ] 
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(continued from preceding page) 

[ CONLOSERS_SESSION_COUNT ( variable ) ] 
[ SESSXON.XDS ( variable ) ] 


Supplied Parameters: 

FULLY_QUALIFIED_LU_NAME specifies the fully qualified name of the 
remote LU. 

MODE_NAME specifies the mode name. 

Returned Parameters: 

RETURN_CODE returns an indication of the result of verb execution. 

• OK 

• PARAMETER_ERROR (for one of the following reasons) 

FULLY_QUALIFIED_LU_NAME does not specify a remote LU name 
currently defined at the local LU. 

— M0DE_NAME does not specify a mode name currently defined at 
the local LU. 

SEND_PACING_>1XND0U returns the local LU T s send pacing window size for 
the sessions* currently defined at the local LU. 

RECEXVE_PACING_WINDOW returns the local LU’s receive pacing window 
size for the sessions* currently defined at the local LU. 

SEND_MAX_RU_SXZE_L01JER_BOUND returns the lower bound for the maximum 
size of normal-flow requests that the local LU sends on the sessions* 
currently defined at the local LU. 

SEND_HAX_RU_SXZE_UPPER_BOUND returns the upper bound for the maximum 
size of normal-flow requests that the local LU sends on the sessions* 
currently defined at the local LU. 

RECEIVE_hAX_RU_SX Z E_L OMER_BOUND returns the lower bound for the maxi¬ 
mum size of normal-flow requests that the local LU receives on the 
sessions* currently defined at the local LU. 

RECEIVEJ1AX_RU_SIZEJJPPER_BOUND returns the upper bound for the maxi¬ 
mum size of normal-flow requests that the local LU receives on the 
sessions* currently defined at the local LU. 

SYNC_LEVEL returns an indication of the synchronization levels that 
are supported for conversations allocated to the sessions. If one or 
more sessions within the mode name group are active between the local 
and remote LUs* this parameter returns an indication of the actual 
synchronization level support* otherwise* it returns an indication of 
the support currently defined at the local LU. 

SXNGLE_SESSION_REXNITXATXON returns an indication of the session 
reinitiation responsibi1ity for a single session with the remote LU. 
If a session is active between the local and remote LUs* this parame¬ 
ter returns an indication of the actual session reinitiation respon¬ 
sibility* otherwise* it returns an indication of the responsibility 
currently defined at the local LU. 

5ESSX0N_LEVEL_CRYPT0GRAPHY returns an indication of the session-level 
cryptography support for the sessions. If one or more sessions within 
the mode name group are active between the local and remote LUs* this 
parameter returns an indication of the actual ^ session-level 
cryptography support* otherwise* it returns an indication of the sup¬ 
port currently defined at the local LU. 
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DXSPLAY_MODE 


C0N14I NNER_AUT 0_ACT X VAT E_L I MI T returns the local UP s 

automatic-activation limit on the number of contention winner ses¬ 
sions* currently defined at the local LU. 

LU_MODE_SESSXON_LXMIT returns the current (LU*mode) session limit* 

HXN_CONMXNNERS returns the current minimum number of sessions for 
which the local LU is designated to be the contention winner. 

MXN_CONLOSERS returns the current minimum number of sessions for 
which the remote LU is designated to be the contention winner* making 
the local LU the contention loser. 

TERMINATION_COUNT returns the termination count* which is the number 
of sessions for which that the local LU is responsible to deactivate 
as a result of CNOS processing. 

DRAXN_LOCAL_LU returns an indication of whether the local LU is 
allowed to drain its allocation requests as a result of CNOS process¬ 
ing that resets the (LU*mode) session limit. 

DRAIN_REMOTE_LU returns an indication of whether the remote LU is 
allowed to drain its allocation requests as a result of CNOS process¬ 
ing that resets the (LU*mode) session limit. 

LU_HODE_SESSXON_COUNT returns the current (LU*mode) session count. 

C0NI4XNNERS__SESSX0N_C0UNT returns the number of active sessions for 
which the local LU is the contention winner. 

CONLOSERS_SESSXON_COUNT returns the number of active sessions for 
which the local LU is the contention loser. 

SESSXONJtDS returns a list of the session identifiers assigned to the 
active sessions. 

ABEND Conditions: 

Parameter Check 

• This verb is not supported. 

• The program issuing this, verb does not have display privilege. 
Notes: 

1. This verb can be used to obtain operating parameter values that 
are established by the DEFINE_MODE verb and the CNOS verbs. 

2. More details concerning the LU f s use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manual: 
Architecture Logic for LU Type 6.2 . 
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DISPLAY_TP 

Returns current values'of parameters that control the operation of the 
local LU in conjunction Mith a transaction program. 


Supplied Parameters: 


DISPLAY_TP 


TP_NAHE ( variable ) 
Returned Parameters: 


[ RETURN.CODE ( variable ) ] 

[ STATUS ( variable ) ] 

[ CONVERSATION.TYPE C variable ) ] 
[ SYNC_LEVEL ( variable ) ] 

[ security.requzred ( variable ) ] 
[ SECURXTY.ACCESS ( variable ) ] 

I" PIP ( variable ) j 
[ DATA_HAPPING C variable ) ] 

[ FMH_DATA I variable ) ] 

[ PRIVILEGE ( variable I ] 


Supplied Parameters: 

TP_NAME specifies the local transaction program name. 

Returned Parameters: 

RETURN_CODE returns an indication of the result of verb execution. 

• OK 

• PARAMETER_ERROR (for the following reason) 

— TP_NAME does not specify a transaction program name that is 
currently defined at the local LU. 

STATUS returns an indication of the status for starting execution of 
the transaction program, as currently defined at the local LU. 

CONVERSATION^TYPE returns an indication of the conversation type 
required on allocation requests that start the transaction program, 
as currently defined at the local LU. 

SYNC_LEVEL returns an indication of the synchronization level 
required on allocation requests that start the transaction program, 
as currently defined at the local LU. 

SECURITY m REQUIRED returns an indication of the type of security ver¬ 
ification that is required to be performed on incoming allocation 
requests designating the transaction program. 
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DISPLAY_TP 


SECURITY_ACCESS returns the resource-access authorization list cur¬ 
rently defined for the transaction program at the local LU. 

PIP returns the number of PIP subfields required on allocation 
requests that start the transaction program, as currently defined at 
the local LU. 

DATA_HAPPING returns an indication of whether data mapping support is 
provided to the transaction program, as currently defined at the local 
LU. 

FMH_DATA returns an indication of whether FMH data support is provided 
to the transaction program, as currently defined at the local LU. 

PRIVILEGE returns an indication of the class of privileged verbs that 
the transaction program is allowed to issue, as currently defined at 
the local LU. 

ABEND Conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have display privilege. 

Notes: 

1. This verb can be used to obtain operating parameter values that 
are established by the DEFINE_TP verb. 

2. More details concerning the LU f s use of these operating parame¬ 
ters are given in SNA Format and Protocol Reference Manuals 
Architecture Logic for LU Type 6,2 . 
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DELETE 


Deletes parameter values, established by means of the DEFINE verbs, 
that control the operation of the local LU. The execution of this 
verb involves only the local LU; it does not cause any information to 
be sent outside the LU. 



Supplied Parameters: 

DELETE 

[ LOCAL_LU_NAME C variable ) ] 


[ REMOTE_LU_NAHE ( variable ) ] 


[ MODE.NAHE ( variable ) ] 


[ TP_NAME ( variable ) ] 


Returned Parameters: 


RETURN.CODE ( variable ) 


9 


Supplied Parameters: 

LOCAL_LU_NAME specifies the fully qualified name of the local LU. 
This parameter must be specified alone. Specifying this parameter 
deletes the local LU name and all parameter values associated with the 
local LU; that is, it deletes all parameter values that have been 
defined by means of the DEFINE L0CAL_LU, DEFINE_REMOTE_LU, 
DEFINEJ10DE, and DEFINEJTP verbs. 

REMOTE_LU_NAME specifies the fully qualified name of the remote LU. 
This parameter may be specified together with the M0DE_NAME parame¬ 
ter. Specifying this parameter without the M0DE_NAME parameter 
deletes the remote LU name and all parameter values associated with 
the remote LU; that is, it deletes all parameter values that have been 
defined by means of the DEFINE_REMQTE_LU and DEFINEJ1QDE verbs. Spec¬ 
ifying this parameter together with the M0DE_NAME parameter deletes 
parameter values associated with the mode name, but the remote LU name 
and all parameter values not associated with the mode name remain 
unchanged. 

MODE_NAME specifies the mode name. This parameter must be specified 
together with the REMOTE_LU_NAME parameter. Specifying this parame¬ 
ter deletes all parameter values associated with the mode name for the 
remote LU; that is, it deletes the mode name and all parameter values 
that have been defined by means of the DEFINE_MQDE_NAME verb. 

TP_NAME specifies the local transaction program name. Specifying 
this parameter deletes all parameter values associated with the 
transaction program; that is, it deletes the program name and all 
parameter values that have been defined by means of the DEFINE_TP 
verb. 

Returned Parameters: 

RETURN_CODE returns an indication of the result of verb execution. 

♦ OK 

♦ PARAMETER_ERROR (for one of the following reasons) 

— LOCAL_LU_NAME specifies a local LU name not currently defined 
at the local LU. 

— LOCAL_LU_NAME is not specified alone. 

— REMOTE^LU_NAME specifies a remote LU name not currently 

defined at the local LU. 
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— MODE_NAME specifies a mode name not currently defined at the 
local LU. 

M0DE_NAME is specified without REMOTE_LU_NAME. 

— TP_NAME specifies a local transaction program name not cur¬ 
rently defined at the local LU. 

ABEND conditions; 

Parameter Check 

• This verb is not supported. 

• The program issuing this verb does not have define privilege. 

Notes: 

1. Deleting parameter values makes those values undefined to the 
local LU. 

2. When deleting a local LU name and all its associated parameter 
values# verb should be issued only when the local LU is not par¬ 
ticipating in any network activity. 

3. When deleting a remote LU name and all its associated parameter 
values# verb should be issued only when the local LU is not par¬ 
ticipating in any network activity involving the remote LU. 

4. When deleting a mode name and all its associated parameter values# 
verb should be issued only when the local LU is not participating 
in any network activity involving the remote LU and mode name. 

5. When deleting a transaction program name and all its associated 
parameter values# verb should be issued only when the transaction 
program is not in use. 

6. More details concerning the LU v s use of the LU-LU session limit 
are given in SNA Format and Protocol Reference Manual: Architec¬ 
ture Logic for LU Type 6.2 . 
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Some verbs have a parameter called RETURN_CODE used to pass a return 
code back to the transaction program at the completion of the LU’s 
execution of a verb. The return code indicates the result of process¬ 
ing the verb on which it is returned. Only one code is returned at a 
time. Other verb-specific information may be passed back in 
verb-unique parameters. See each specific verb for a description of 
any verb-unique parameters. 

The return codes are described below. Each description includes the 
meaning of the return code and the origin of the condition indicated 
by the return code. 

ACTIVATIQN_FAILURE_NO_RETRY indicates the ACTIVATE_SESSION verb 
failed to activate the session because of a condition that is not 
temporary. For example, the session cannot be activated because 
the (LU,mode) session limit for the specified target LU and mode 
name is currently 0 at the target LU—this applies to single ses¬ 
sions and to sessions for the SNASVCMG mode name; or because of a 
system definition error or a session-activation protocol error. 
The control operator should not retry the transaction until the 
condition is corrected. 

ACTIVATION_FAlLURE_RETRY indicates the ACTIVATE_SESSION verb 
failed to activate the session because of a temporary condition. 
For example, the session cannot be activated because of a tempo¬ 
rary lack of resources at the source LU or target LU. The control 
operator may retry the session activation later. 

ALLOCATXON_ERROR indicates the CNOS verb did not execute success-* 
fully because the allocation of the control operator conversation 
with the target LU cannot be completed. The ALL0CATI0N_ERR0R 
indication together with one of the following subcodes form the 
complete return code that is returned to the transaction program; 
the subcode identifies the specific error. The source and target 
LUs 1 CNOS parameters are not changed. 

- ALLOCATIONJ^AILURE.NO.RETRY indicates the control operator 
conversation cannot be allocated because of a condition that 
is not temporary. For example, the session to be used for the 
control operator conversation cannot be activated because the 
(LU,mode) session limit for the specified target LU and 
SNASVCMG mode name is currently 0 at either the source LU or 
target LU; or because of a system definition error or a 
session-activation protocol error; or because a session pro¬ 
tocol error caused the session to be deactivated before the 
conversation could be allocated. The control operator should 
not retry the transaction until the condition is corrected. 

- ALLOCATION_FAILURE_RETRY indicates the control operator con¬ 
versation cannot be allocated because of a temporary condi¬ 
tion. For example, the session to be used for the control 
operator conversation cannot be activated because of a tempo¬ 
rary lack of resources at the source LU or target LU; or the 
session was deactivated because of session outage before the 
conversation could be allocated. The condition is temporary, 
and the control operator can retry the transaction later. 

— TRANS_PGM_NOT_AVAIL_RETRY indicates the target LU is current¬ 

ly unable to start the transaction program identified as hex 
06F1, which is the SNA service transaction program for the 
control operator. For example, there may be a temporary lack 
of resources the target LU needs to start the transaction pro¬ 
gram. The condition is temporary, and the control operator 
can retry the transaction later. 

COMMAND_RACE_REJECT indicates the CNOS verb did not execute suc¬ 
cessfully because the source LU or target LU is currently process¬ 
ing another CNOS transaction for the same mode name. The other 
CNOS transaction is processed to completion. The source and tar¬ 
get LUs 1 CNOS parameters are not changed by the unsuccessful CNOS 
verb. 
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LU_HODE_SESSION_LIMIT_CLOSED indicates the CNOS verb did not exe¬ 
cute successfully because the target LU currently Mill not alloM 
the (LU#mode) session limit for the specified mode name to be 
raised above 0. The (LU#mode) session limit remains at 0. This 
condition is not necessarily permanent; the control operator may 
retry the CNOS transaction later. 

LU_MODE_SESSION_LIMITJEXCEEDED indicates the ACTIVATE_SESSION 
verb could not activate the session with the specified mode name 
to the target LU# for one of the follouing reasons: 

1. For a single session connection to the target LU# either the 
(LU#mode) session limit is currently 0# or an LU-LU session is 
already active (with the specified or a different mode name). 

2. For a parallel session connection to the target LU# the number 
of currently active sessions with the specified mode name 
equals the (LU#mode) session limit. 

LU_MODE_SESSIONJLIMIT_NOT_ZERO indicates the program attempted to 
initialize an (LU#mode) session limit that is already initial¬ 
ized# that is# the session limit is already greater than 0. The 
source and target LUs* CNOS parameters are not changed. 

LU_MODE_SESSION_LIMIT_ZERO indicates the program attempted to 
change an (LU#mode) session limit that has not been initialized# 
that is# the session limit is 0. The source and target LUs f CNOS 
parameters are not changed, 

LU_SESSION_LIMITJEXCEEDED indicates the CNOS verb did not execute 
successfully because the new (LU#mode) session limit would cause 
the sum of the (LU#mode) session limits to exceed the total LU-LU 
session limit for the source LU (see the DEFINE_LOCAL_LU verb). 
The sum of the (LU#mode) session limits is calculated as follows: 

1. A single session connection to a target LU is counted as 1 if 
at least one of the (LU#mode) session limits for that target 
LU is 1# including the specified session limit. Otherwise# it 
i s counted as 0. 

2. A parallel session connection to a target LU is counted as the 
sum of all (LU#mode). session limits for the target LU# includ¬ 
ing the specified session limit. 

OK indicates the verb executed successfully. The following sub¬ 
codes augment this return code and indicate whether the parameter 
values were processed as specified or as negotiated by the target 
LU: 

— AS_SPECIFIED indicates the two LUs executed the verb as spec¬ 
ified# without negotiation. 

— AS_NEGOTIATED indicates the two LUs executed the verb as 
negotiated by the target LU. One or more parameter values 
have been negotiated. The transaction program can obtain the 
negotiated parameter values by issuing the DISPLAY^MODE verb. 
The verb descriptions define which parameter values can be 
negotiated. 

— FORCED indicates the source LU forced the resetting of its 
(LU#mode) session limit as a result of an error condition that 
prevented successful completion of the exchange of the CNOS 
request and reply. The target LU f s CNOS parameters may not be 
changed# depending on the error condition and when it 
occurred during the CNOS exchange. 

PARAMETER_ERROR indicates the verb did not execute successfully 
because it specifies a parameter that contains an invalid argu¬ 
ment. The source of the argument may be outside the transaction 
program definition# such as a control-operator supplied LU name 
or mode name. When this return code is returned on a CNOS verb# 
the source and target LUs 1 CNOS parameters are not changed. When 
it is returned on a session activation or deactivation verb# the 
LU-LU session is not activated or deactivated# respectively. 
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When it is returned on a define* display* or delete verb* the LU 
operating parameters are not altered or returned* 

REQUEST_EXCEEDS_MAX_ALLOUED indicates the CNOS verb did not exe¬ 
cute successfully because it specifies an (LU*mode) session limit 
that exceeds the source LU v s maximum (LU*mode) session limit 
defined for the target LU and mode name (see the DEFINE_MODE 
verb). The source and target LUs 1 CMOS parameters are not 
changed. 

RESOURCE_FAILURE_NO_RETRY indicates the CNOS verb did not execute 
successfully because of a failure that caused the control opera¬ 
tor conversation to be prematurely deallocated. For example* the 
session being used for the control operator conversation was 
deactivated because of a session protocol error* or because of 
session outage from which the control operator component of the LU 
could not recover; or the conversation was deallocated because of 
a protocol error between the control operator components of the 
LUs. The condition is not temporary* and the control operator 
should not retry the transaction until the condition is coi— 
rected. The CNOS parameters remain unchanged at the source LU* or 
both the source and target LUs* depending on when the failure 
occurred. 

UNRECOGNIZED_MODE_NAME indicates the CNOS verb did not execute 
successfully because the target LU does not recognize the speci¬ 
fied mode name. The source and target LUs* CNOS parameters are 
not changed. 

Figure 5-1 on page 5-54 shows the correlation of the return codes to 
the verbs on which they can be returned. The "X" in the figure means 
the return code can be returned on the corresponding verb. A verb 
without any ?, X"s under it means no return codes are defined for the 
verb. The individual verb descriptions list the applicable return 
codes. However* the subcodes of ALLQCATION_ERROR are not explicitly 
listed* as any of them can be returned as part of the ALLOCATION_ERROR 
return code. 
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Figure 5-1. Correlation of Return Codes to Verbs 
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APPENDIX A. BASE AND OPTION SETS FOR PRODUCT SUPPORT 


The LU 6*2 functions available to a transaction program are described 
in this book by means of verbs and their supplied and returned parame¬ 
ters. The returned parameters include the return codes of the 
RETURN_CODE parameter, defined for most verbs, and the what-received 
indications of the WHAT_RECEIVED parameter, defined for the 
MC_RECEIVE_AND_WAIT, MC_RECEIVE_IMMEDIATE, RECEI VE_ANDJ*IAIT, and 
RECEIVE_IMMEDIATE verbs. 

An LU 6.2 product may provide support for all of the verbs, parame¬ 
ters, return codes, and what-received indications, or a permitted 
subset of them. The permitted subsetting for LU 6.2 products is 
defined by means of a base set and a number of option sets (see 
"Product-Support Subsetting" in Chapter 3 for a discussion of base and 
option sets). The option sets defined for the verbs, parameters, 
return codes, and what-received indications are: 1 

1. Conversations between programs located at the same LU: This 
option set allows a local program to allocate a conversation to a 
remote program located at the same LU as the local program. 

2. Delayed allocation of a session: This option set allows a program 
to delay allocation of a session until the LU must flush its send 
buffer. 

3. Immediate allocation of a session: This option set allows a pro¬ 
gram to allocate a contention-winner session only if one is imme¬ 
diately available; otherwise, the allocation is unsuccessful. 

4* Sync point services: This option set allows a program to request 
sync point processing of all protected resources throughout the 
scope of the transaction. This option set includes the SYNCPT and 
BACKOUT verbs. 

5. Session-level LU-LU verification: This option set allows a pro¬ 
gram or operator to designate the LU-LU passwords, associated 
with remote LUs, that the local LU uses to verify the identity of 
a remote LU at session activation time. 

6. User ID verification: This option set allows a program or opera¬ 
tor to designate the user IDs and associated passwords that the 
local LU uses to verify the identity of a user ID carried on allo¬ 
cation requests it receives, and to designate the remote LUs that 
are permitted to send to the local LU allocation requests carrying 
a user ID and either a password or an already-verified indication. 
This option set also allows the program allocating a conversation 
to specify that the allocation request carry the user ID received 
on the request that started the program, together with an 
already-verified indication. Option set 5 is a prerequisite. 

7. Program supplied user ID and password: This option set allows the 
program allocating a conversation to supply the user ID and pass¬ 
word to be sent on the allocation request. Option set 5 is a pre¬ 
requi si te. 

8. User ID authorization: This option set allows a program or opera¬ 
tor to designate the user IDs that are authorized access to spe¬ 
cific resources of the LU, such as transaction programs. Option 
set 6 is a prerequi si te. 

9. Profile verification and authorization: This option set allows a 
program or operator to designate the profiles that the local LU 
uses to verify a profile carried on allocation requests it 


The numbers associated with these option sets are used only for 
descriptive purposes; they have no architectural significance, 
and may change from one edition of this book to the next. 
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receives* and • to designate the profiles that are authorized 
access to specific resources of the LU* such as transaction pro¬ 
grams* Option set 6 is a prerequisite. 

10. Profile passthrough: This option set allots the program allocat¬ 
ing a conversation to specify that the allocation request carry 
the profile received on the request that started the program. 
Option set 6 is a prerequi si te. 

11. Program supplied profile: This option set allows the program 
allocating a conversation to supply the profile to be sent on the 
allocation request. Option set 7 is a prerequisite. 

12. PIP data: This option set allows the program allocating a conver¬ 
sation to provide the remote program with initialization parame¬ 
ters. 

13. Logging of data in a system log: This option set allows a program 
to record error information in the system 1 s error log. 

14. Flush the LU’s send buffer: This option set allows a program to 
explicitly cause the LU to flush its send buffer. 

15. LUW identifier: This option set allows an LU implementation to 
use the LUW identifier for accounting purposes. 

16. Prepare to receive: This option set allows a program to change 
the conversation from send state to receive state and at the same 
time flush the LU f s send buffer* request confirmation* or request 
sync point. 

17. Long locks: This option set allows a program to perform the 
prepare-to-receive function and request confirmation* and resume 
processing when information* such as data or conversation status* 
is received from the remote program following an affirmative 
reply. Option set 16 is a prerequi si te. 

18. Post on receipt With wait: This Option set allows a program to 

request posting of multiple conversations and then to wait (sus¬ 

pend its processing) until information is available on any one of 
the conversations. Option set 16 is a prerequisite. 

19. Post on receipt with test for posting: This option set allows a 

program to request posting of a conversation and then to test the 

conversation to determine whether information is available. 
Option set 16 is a prerequi si te. 

20. Receive immediate: This option set allows a program to receive 
whatever information is available on a conversation without hav¬ 
ing to request posting of the conversation. Option set 16 is a 
prerequisite. 

21. Test for request-to-send received: This option set allows a pro¬ 
gram to test whether a request-to-send notification has been 
received on a conversation* for example following sync point 
processing. 

22. Data mapping: This option set allows a program to request mapping 
of the data by the local and remote LUs. 

23. FMH data: This option set allows programs to send and receive 
data records containing FM header data. The FM header data has 
meaning only to the application programs. 

24. Get attributes: This option set allows a program to obtain attri¬ 
butes of a mapped conversation. 

25. Get conversation type: This option set allows a program that sup¬ 
ports both the basic conversation and mapped conversation proto¬ 
col boundaries to determine which category of verbs it should use 
in conjunction with a resource ID. 
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26. Happed Conversation Lll Services Component: This option set 
allows implementation of a mapped conversation LU services compo¬ 
nent program* which processes mapped conversation verbs. 

27. CHANGERSESS I ON_LZ MIT verb: This option set allows a program or 
operator at the source LU to request a change in the (LU*mode) 
session limit from one nonzero value to another* or a change in 
the minimum number of contention-winner sessions for the source 
LU or target LU. 

28. MIN_CONMINNERS_TARGET parameter: This option set allows a pro¬ 
gram or operator at the source LU to request a nonzero value for 
the target LU's minimum number of contention-winner sessions. 
Option set 27 is a prerequisite for this parameter on 
CHANGE_SE5SI0N_LIMIT. 

29. RESPONSIBLECTARGET) parameter: This option set allows a program 
or operator at the source LU to request that the target LU be 
responsible for session deactivations when the verb requires a 
decrease in the number of active sessions. Option set 27 is a 
prerequisite for this parameter on CHANGE_$ESSION_LIMIT. 

30. DRAXN_TARGET(NO) parameter: This option set allows a program or 
operator at the source LU to prevent the target LU from draining 
its allocation requests as a result of resetting the (LU*mode) 
session limit to 0. 

31. FORCE parameter: This option set allows a program or operator to 
specify that the (LU*mode) session limit is to be reset to 0 even 
if the CNOS exchange between the source LU and target LU is unsuc¬ 
cessful . 

32. ACTXVATE_SESSION verb: This option set allows a program or opera¬ 
tor to activate LU-LU sessions. 

33. DEACTXVATE_SESSXON verb: This option set allows a program or 
operator to deactivate LU-LU sessions. 

34. LU-parameter verbs: This option set allows a program or operator 
to specify the operating parameters of its LU. Within this option 
set* the individual operating parameters that a product supports 
and makes accessible to the program or operator are 
product-dependent. 

35. LU-LU session limit: This option set allows a program or operator 
to specify the LU-LU session limit. 

36. Locally-known LU names: This option set allows a program or oper¬ 
ator to specify the locally-known names of remote LUs. 

37. Uninterpreted LU names: This option set allows a program or oper¬ 
ator to specify the uninterpreted names of remote LUs. 

38. Single-session reinitiation: This option set allows a program or 
operator to specify the responsibility for reinitiation of single 
sessions to remote LUs. 

39. Maximum RU size bounds: This option set allows a program or opei— 
ator to specify the lower and upper bounds for the maximum RU 
sizes on sessions within an (LU*mode) group. 

40. Session-level mandatory cryptography: This option set allows a 
program or operator to specify that session-level mandatory 
cryptography i s to be used on sessions within an (LU*mode) group. 

41. Contention winner automatic activation limit: This option set 
allows a program or operator to specify the limit for automat¬ 
ically activating contention-winner sessions within an (LU*mode) 
group. 

The following figures identify local and remote support of the base 

set and option sets for the verbs* parameters* return codes* and 

what-received indications. Local support is defined for all of these. 

Remote support is defined only for the verbs and parameters* as it 
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does not apply to the return codes and what-received indications. Two 
hyphens (—) are shown for remote support of a verb or parameter that 
does not invoke remote processing. 

The verbs# parameters# return codes# and what-received indications 
belonging to the base set are identified by "B" in the local-support 
or remote-support column. Those belonging to an option set are iden¬ 
tified by the number of that option set. 

For some of the verbs# parameters# return codes# and what-received 
indications# more than one option set is identified. An identifica¬ 
tion of the form "a or b” means the verb# parameter# return code# or 
what-recei ved indication is supported when either option set ,f a” or 
"b" is supported. An identification of the form "a and b" means the 
verb# parameter# return code# or what-received indication is sup¬ 
ported when both option sets ft a ,f and ,T b" are supported. 

Notes pertaining to the base and optional support of the verbs# param¬ 
eters# return codes# and what-received indications are listed follow¬ 
ing the figures# beginning on page A-20. The verbs# parameters# 
return codes# and what-received indications to which the notes apply 
include a note reference# shown as "Cnl#" in the local- or 
remote-support column. The notes explain certain implementation 
details# which are product dependent. 

Note: As shown in the figures for the conversation verbs and parame¬ 
ters# most of the option sets are optional only for local support# 
remote support for the verbs and parameters of these option sets is 
either part of the base set (indicated with "B") or is not applicable 
(indicated with ”—"). The local program may use these conversation 
verbs and parameters whenever its product supports them. Use of the 
remaining conversation verbs and parameters—those for which remote 
support of an option set is shown—depends on the remote support that 
the remote product provides. In particular# the local program may use 
the verbs and parameters of the following option sets whenever its 
product supports them and the remote product provides the support 
indicated in the remote-support column: 

4. Sync point services 

6. End-user verification 

7. Program supplied user ID and password 

10. Profile passthrough 

11. Program supplied profile 

12. PIP data 

22. Data mapping 

23. FMH data 
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SUPPORT FOR MAPPED CONVERSATION VERBS AND PARAMETERS 


Verb and Parameter 

Local Support 

Remote Support 

MC ALLOCATE 

B 

B C1I 

LU NAMECOWN) 

1 

— 

LU NAME(OTHER(variable)) 

B 

B 

MODE NAME 

B 

B 

TPN 

B 

B 

RETURN CONTROL(MHEN SESSION ALLOCATED) 

B [21 

-- 

RETURN CONTROL(DELAYED ALLOCATION PERMITTED) 

2 

— 

RETURN CONTROL(IMMEDIATE) 

3 

— 

SYNC LEVEL(NONE) 

B 

B 

SYNC LEVEL(CONFIRM) 

B 

B 

SYNC LEVEL(SYNCPT) 

4 

4 

SECURITY(NONE) 

B 

B 

SECURITYCSAME) 

6 or 10 [31 

6> 8> 9 or 

10 

SECURITY(PGM(USER ID(variable) 

7 

6 or 8 

PASSU0RD(variable) 

7 

6 

PR0FILE(variable))) 

ii 

9 or 10 

PIP(NO) 

B 

B 

PIP(YES(variable)) 

12 [4] 

12 [4] 

RESOURCE 

B 

— 

RETURN_CODE 

B 

— 

MC_CONFIRM 

B 

B 

RESOURCE 

B 

-- 

RETURN CODE 

B 

— 

REQUEST_TO_SEND_RECEIVED 

B 

— 

MC CONFIRMED 

B 

B 

RESOURCE 

B 

— 

MC DEALLOCATE 

B 

B 

RESOURCE 

B 

— 

TYPE(SYNC LEVEL) 

B 

B 

TYP-E( FLUSH) 

B 

B 

TYPE(CONFIRM) 

B 

B 

TYPE(ABEND) 

B 

B 

TYPE(LOCAL) 

B 

— 

RETURN_CODE 

B 

— 

MC FLUSH 

14 

B 

RESOURCE 

14 



| Figure A-l. Support for Mapped Conversation Verbs and Parameters (Part 1 of 3) 
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Verb and Parameter 

Local Support 

Remote Support 

MC_GET_ATTRIBUTES 

4, 6, 9, 15, 

— 


or 24 


RESOURCE 

4, 6, 9, 15, 

— 


or 24 


OWN_FULLY_QUALIFIED_LU NAME 

24 

«—- 

PARTNER LU NAME 

24 

— 

PARTNER FULLY QUALIFIED LU NAME 

24 

— 

MODE NAME 

24 

— 

SYNC LEVEL 

4 or 24 


SECURITY USER ID 

6 

— 

SECURITY PROFILE 

9 

— 

LUW IDENTIFIER 

4 or 15 

— 

CONVERSATION_CORRELATOR 

4 

— 

MC_POST_ON_RECEIPT 

18 or 19 [53 

— 

RESOURCE 

18 or 19 

— 

LENGTH 

18 or 19 CIO] 

" 

MC PREPARE TO.RECEIVE 

16 

B 

RESOURCE 

16 

— 

TYPE(SYNC LEVEL) 

16 

B 

TYPE(FLUSH) 

16 

B 

TYPE(CONFIRM) 

16 

B 

LOCKS(SHORT) 

16 

B 

LOCKS(LONG) 

17 

B 

RETURN_CODE 

16 

— 

MC_RECEIVE_AND WAIT 

B [6] 

— 

RESOURCE 

B 

— 

LENGTH 

B [101 

— 

RETURN_CODE 

B 

— 

REQUEST_TO_SEND_RECEIVED 

B [9] 

— 

DATA 

B 

— 

WHAT_RECEIVED 

B [7] 

— 

MAP_NAME 

22 


MC_RECEIVE_IMMEDIATE 

20 

— 

RESOURCE 

20 

— 

LENGTH 

20 [10] 

— 

RETURN.CODE 

20 

— 

REQUEST TO SEND RECEIVED 

20 [9] 

— 

DATA 

20 

— 

WHAT RECEIVED 

20 [7] 

— 

MAP_NAME 

20 and 22 

— 

MC REQUEST TO SEND 

B [8] 

B 

RESOURCE 

B 



Figure A-2. Support for Happed Conversation Verbs and Parameters (Part 2 of 3) 
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Figure A-3. Support for Napped Conversation Verbs and Parameters (Part 3 of 3) 
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SUPPORT FOR TYPE-INDEPENDENT CONVERSATION VERBS AND PARAMETERS 



| Figure A-4* Support for Type-Independent Conversation Verbs and Parameters 
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SUPPORT FOR BASIC CONVERSATION VERBS AND PARAMETERS 


Verb and Parameter 

Local Support 

Remote Support 

ALLOCATE 

B 

B [13 

LU NAME(OWN) 

1 

-- 

LU_NAME(OTHER(variable)) 

B 

B 

MODE NAME 

B 

B 

TPN 

B 

B 

TYPECBASIC CONVERSATION) 

B 

B 

TYPECMAPPED CONVERSATION) 

26 

B 

RETURN_C0NTR0L(WHEN SESSION ALLOCATED) 

B [21 

— 

RETURN_CONTROL(DELAYED ALLOCATION_PERMITTED) 

2 

— 

RETURN CONTROL ( IMMEDIATE) 

3 

— 

SYNC_LEVEL(NONE) 

B 

B 

SYNC LEVEL(CONFIRM) 

B 

B 

SYNC LEVELCSYNCPT) 

4 

4 

SECURITY(NONE) 

B 

B 

SECURITY(SAME) 

6 or 10 133 

6 r 8, 9 or 



10 

SECURITY(PGM(USER ID(variable) 

7 

6 or 8 

PASSWORD(variable) 

7 

6 

PROFILE(variable))) 

ii 

9 or 10 

PIP(NO) 

B 

B 

PIP(YES(variable)) 

12 [43 

12 [43 

RESOURCE 

B 


RETURN_CODE 

B 


CONFIRM 

B 

B 

RESOURCE 

B 

— 

RETURN_CODE 

B 

— 

REQUEST_TO_SEND_RECEIVED 

B 

—— 

CONFIRMED 

B 

B 

RESOURCE 

B 

— — 

DEALLOCATE 

B 

B 

RESOURCE 

B 

— 

TYP E(SYNC_L EVEL ) 

B 

B 

TYPE(FLUSH) 

B 

B 

TYPE(CONFIRM) 

B 

B 

TYPE(ABEND PROG) 

B 

B 

TYPE(ABEND SVC) 

26 [143 

B 

TYPE(ABEND TIMER) 

26 [143 

B 

TYPE(LOCAL) 

B 

— 

LOG DATA(NO) 

B 

B 

LOG DATA(YES(variable)) 

13 

B [153 

RETURN_CODE 

B 


FLUSH 

14 

B 

RESOURCE 

14 

— 


Figure A-5. Support for Basic Conversation Verbs and Parameters (Part 1 of 3) 
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Verb end Parameter 

Local Support 

Remote Support 

GET_ATTRIBUTES 

B 

_ 

RESOURCE 

B 

— 

0WN_FUL LY_QUALIFIED_IU_NAME 

B 

— 

PARTNER LU NAME 

B 

— 

PARTNER FULLY_QUALIFIED LU NAME 

B 

— 

MODE NAME 

B 

— 

SYNC LEVEL 

B 

— 

SECURITY_USER_ID 

6 

— 

SECURITY PROFILE 

9 

— 

LUW IDENTIFIER 

4 or 15 

— 

C0NVERSATI0N_C0RRELAT0R 

4 

— — 

POST ON RECEIPT 

18 or 19 [53 

— 

RESOURCE 

18 or 19 

— 

FILL(LL) 

18 or 19 [161 

— 

FILL(BUFFER) 

18 or 19 [16] 

— 

LENGTH 

18 or 19 


PREPARE TO_RECEIVE 

wMmmmm 

B 

RESOURCE 


— 

TYPE(SYNC_LEVEL) 


B 

TYPECFLUSH) 

16 

B 

TYPE(CONFIRM) 

16 

B 

LOCKS(SHORT) 

16 

B 

LOCKS(LONG) 

17 

B 

RETURN_CODE 

16 

— 

RECEIVE AND WAIT 

B [6] 

— 

RESOURCE 

B 

— 

FILL(LL) 

B [16] 

— 

FILL(BUFFER) 

B [16] 


LENGTH 

B 

— 

RETURN CODE 

B 

— 

REQUEST_TO_SEND_RECEIVED 

B [9] 

“ 

DATA 

B 

-- 

WHAT_RECEIVED 

B [7] 

— 

RECEIVE.IMMEDIATE 

20 

— 

RESOURCE 

20 

— 

FILL(LL) 

20 [16] 

—- 

FILL(BUFFER) 

20 [16] 

— 

LENGTH 

20 

— 

RETURN CODE 

20 

— 

REQUEST_TO_SEND_RECEIVED 

20 [9] 

— 

DATA 

20 

—— 

WHAT_RECEIVED 

20 [7] 

" 

REQUEST TO SEND 

B [8] 

B 

RESOURCE 

B 



Figure A-6. Support for Basic Conversation Verbs and Parameters (Part 2 of 3) 
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Verb and Parameter 

Local Support 

Remote Support 

SEND DATA 

B 

B 

RESOURCE 

B 

-- 

DATA 

B 

B 

LENGTH 

B 

B 

RETURN CODE 

B 

— 

REQUEST_TO_SEND_RECEIVED 

B 

— 

SEND ERROR 

B 

B 

RESOURCE 

B 

— 

TYPE(PROG) 

B 

B 

TYPE(SVC) 

26 CIA] 

B 

LOG DATA(NO) 

B 

B 

LOG DATA(YES(variable)) 

13 

B C153 

RETURN.CODE 

B 

— 

REQUEST_TO_SEND_RECEIVED 

B 

— 

TEST 

19 or 21 

— 

RESOURCE 

19 or 21 

— 

TEST(POSTED) 

19 

— 

TEST(REQUEST TO SEND RECEIVED) 

21 

— 

RETURN_CODE 

19 or 21 



Figure A-7. Support for Basic Conversation Verbs and Parameters (Part 3 of 3) 
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SUPPORT FOR CONVERSATION RETURN CODES AND tlHAT-RECEIVEP INDICATIONS 


Return Code 

Local Support 

ALLOCATION_ERROR 

ALLOCATION FAILURE NO RETRY 

ALLOCATION FAILURE RETRY 

CONVERSATION TYPE MISMATCH 

PIP NOT ALLOWED 

PIP NOT SPECIFIED CORRECTLY 
SECURITY_NOT_VALID 

SYNC LEVEL_N0T SUPPORTED BY PGM 
SYNC_LEVEL_NOT SUPPORTED BY LU 

TPN NOT RECOGNIZED 

TRANS PGM NOT AVAIL NO RETRY 
TRANS_PGM_NOT_AVAIL_RETRY 

B 

B 

B 

B 

12 

B 

6> 7, 10 or 

11 

B 

4 

B 

B 

B 

BACKED_OUT 

4 

DEALLOCATE_ABEND_PROG 

B 

DEALLOCATE_ABEND_SVC 

B 

DEALLOCATE_ABEND_TIMER 

B 

DEALLOCATE_NORMAL 

B 

FMH_DATA_NOT_SUPPORTED 

23 

HEURISTIC_MIXED 

4 

MAP_EXECUTION_FAILURE 

22 

MAP_NOT_FOUND 

22 

MAPPING_NOT_SUPPORTED 

22 

OK 

B 

DATA 

18 or 19 

N0T_DATA 

18 or 19 

PARAMETER_ERROR 

B 

POSTING_NOT_ACTIVE 

18 or 19 

PROG_ERROR_NO_TRUNC 

B 

PROG_ERROR_PURGING 

B 

RESOURCE_FAILURE_NO_RETRY 

B 

RESOURCE_FAILURE_RETRY 

B 

SVC_ERROR_NO_TRUNC 

B 

SVC_ERROR_PURGING 

B 

SVC_ERROR_TRUNC 

B 

UNSUCCESSFUL 

3, 19, 20 or 
21 


Figure A-8. Support for Conversation Return Codes 
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What-Received Indication 

Local Support 

CONFIRM 

B 

CONFIRM_DEALLOCATE 

B 

CONFIRM_SEND 

B 

DATA 

B 

DATA_COMPLETE 

B 

DATA_INCOMPLETE 

B 

DAT A_TRUNCATED 

B [13] 

FMH_DATA_COMPLETE 

23 

FMH_DATA_INCOMPLETE 

23 

FMH_DAT A_TRUNCATED 

23 [13] 

LL_TRUNCATED 

B [17] 

SEND 

B 

TAKE_SYNCPT 

4 

TAKE_SYNCPT_DEALLOCATE 

4 

T AKE_SYNCPT_S END 

4 


| Figure A-9« Support for Conversation What-Receiv,ed Indications 
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SUPPORT FOR CONTROL-OPERATOR VERBS AND PARAMETERS FOR CMOS 


Verb and Parameter 

Local Support 

Remote Support 

CHANGE SESSION_LIMIT 

27 

B 

LU NAME 

27 

B 

M0DE_NAME 

27 

B 

LU MODE SESSION LIMIT 

27 

B 

MIN CONMINNERS SOURCE 

27 

B 

MIN CONMINNERS TARGET 

28 

B 

RESPONSIBLE(SOURCE) 

27 

B 

RESPONSIBLECTARGET) 

29 

B [19] 

RETURN_CODE 

27 

— — 

INITIALIZE_SESSION LIMIT 

B 

B 

LU NAME 

B 

B 

MODE NAME 

B 

B 

LU_MODE_SESSION_LIMIT 

B 

B 

MIN CONMINNERS SOURCE 

B 

B 

MIN CONMINNERS_TARGET 

28 

B 

RETURN_CODE 

B 

— 

PROCESS_SESSION_LIMIT 

B 

B 

LU.NAME 

B 

— 

MODE NAME 

B 

— 

RETURN_CODE 

B 

—— 

RESET w SESSION_LIMIT 

B 

B 

LU NAME 

B 

B 

MODE_NAME(ALL) 

B 

B 

M0DE_NAMEC0NE(variable)) 

B 

B 

RESPONSIBLE(SOURCE) 

B 

B 

RESPONSIBLE(TARGET) 

29 

B [19] 

DRAIN SOURCE(NO) 

B C18] 

B 

DRAIN SOURCE(YES) 

B [18] 

B 

DRAIN_TARGET(NO) 

30 

B 

DRAIN TARGET(YES) 

B 

B C20] 

FORCE(NO) 

B 

B 

FORCE(YES) 

31 

B 

RETURN CODE 

B 



Figure A-10. Support for Control Operator Verbs and Parameters for CNOS 


A-14 


SNA Transaction Programmer's Reference Manual for LU Type 6.2 















SUPPORT FOR CONTROL-OPERATOR VERBS AND PARAMETERS FOR SESSION CONTROL 


Verb and Parameter 

Local Support 

Remote Support 

ACTIVATE SESSION 

32 

B 

LU NAME 

32 

B 

MODE NAME 

32 

B 

RETURN_CODE 

32 

— 

DEACTIVATE_SESSION 

33 

B 

SESSION ID 

33 

— 

TYPE(CLEANUP) 

33 

B 

TYPE(NORMAL) 

RETURN CODE 

33 

33 

B 


Figure A-ll. Support for Control Operator Verbs and Parameters for Session Control 
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SUPPORT FOR CONTROL-OPERATOR VERBS AMD PARAMETERS FOR LU DEFINITION 


Verb and Parameter 

Local Support 

Remote Support 

DEFINE^LOCAL LU 

34 


FULLY_QUALIFIED LU_NAME 

34 

— 

LU_SESSION LIMIT(NONE) 

34 

— 

LU_SESSION LIMIT(VALUE(variable)) 

34 and 35 


SECURITY(ADD(USER ID(variable) 

34 and 6 

— 

PASSWORD(variable) 

34 and 6 

— 

PROFILECvariable))) 

34 and 9 

— 

SECURITY(DELETE(USER ID(variable) 

34 and 6 

— 

PROFILE(variable))) 

34 and 9 

— 

MAP_NAME(ADD(variable)) 

34 and 22 

— 

MAP_NAME(DELETE(variable)) 

34 and 22 

— 

RETURN_CODE 

34 

-- 

DEFINE REMOTE LU 

34 

_ _ 

FULLY_QUALIFIED LU NAME 

34 

— 

LOCALLY_KNOWN_LU_NAME(NONE) 

34 

-- 

LOCALLY_KNOWN_LU_NAME(NAME(variable)) 

34 and 36 

— 

UNINTERPRETED_LU NAME(NONE) 

34 

— 

UNINTERPRETED_LU_NAME(NAME(variable)) 

34 and 37 

— 

INITIATE_TYPE(INITIATE ONLY) 

34 

— 

INITIATE_TYPE(INITIATE OR QUEUE) 

34 

-- 

PARALLEL_SESSION SUPPORT(YES) 

34 

— 

PARALLEL_SESSION_SUPPORT(NO) 

34 

— 

CN0S_SUPP0RT(YES) 

34 

— 

CN0S_SUPP0RT(N0) 

34 

— 

LU_LU_PASSWORD(NONE) 

34 

— 

LU_LU_PASSWORD(VALUE(variable)) 

34 and 5 

— 

SECURITY_ACCEPTANCE(NONE) 

34 

— 

SECURITY_ACCEPTANCE(CONVERSATION) 

34 and 6 

— 

SECURITY_ACCEPTANCE(ALREADY VERIFIED) 

34 and 6 

— 

RETURN_CODE 

34 

— 

DEFINE MODE 

34 [21] 

_ __ 

FULLY_QUALIFIED_LU NAME 

34 

— 

MODE NAME 

34 

— 

SEND.PACING WINDOW 

34 

— 

RECEIVE.PACING WINDOW 

34 

— 

SEND_MAX_RU_SIZE LOWER B0UND(256) 

34 

— 

SENDJ1AX_RU_SIZE_L0WER B0UND(-256) 

34 and 39 

-- 

SEND_MAX_RU_SIZE_UPPER B0UND(256) 

34 

— 

SEND_MAX_RU_SIZE_UPPER B0UND(-256) 

34 and 39 

— 

RECEIVE_MAX_RU SIZE LOWER B0UND(256) 

34 

— 

RECEIVE_MAX_RU_SIZE LOWER B0UND(-256) 

34 and 39 

— 

RECEIVE_MAX_RU SIZE UPPER B0UND(256) 

34 

— 

RECEIVE_MAX_RU SIZE UPPER B0UND(-256) 

34 and 39 

— 

SYNC_LEVEL SUPPORT(CONFIRM) 

34 

— 

SYNC_LEVEL_SUPPORT(CONFIRM SYNCPT) 

34 and 4 

— 

SINGLE_SESSION_REINITIATION(OPERATOR) 

34 

— 

SINGLE_SESSION REINITIATION(PLU) 

34 and 38 

— 

SINGLE SESSION REINITIATION(SLU) 

34 and 38 

— 

SINGLE_SESSION_REINITIATION(PLU OR SLU) 

34 and 38 

-- 

SESSI0N_L EVEL_CRYPTOGRAPHY(NO) 

34 

— 

SESSION_LEVEL_CRYPTOGRAPHY(YES) 

34 and 40 

— 

CONWINNER_AUTO ACTIVATE LIMIT 

34 and 41 

— 

RETURN CODE 

34 

— 


Figure A-12. Support for Control Operator Verbs and Parameters for LU Definition 
(Part 1 of 3) 
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Verb and Parameter 

Local Support 

Remote Support 

DEFINE TP 

34 

_ 

TP NAME 

34 

— 

STATUS(ENABLED) 

34 

— 

STATUStTEMP DISABLED) 

34 

— 

STATUS(PERM DISABLED) 

34 

-- 

CONVERSATION TYPE(MAPPED) 

34 

— 

CONVERSATION TYPECBASIC) 

34 

— 

SYNC LEVEL(NONE) 

34 

— 

SYNC LEVEL(CONFIRM) 

34 

— 

SYNC LEVEL(SYNCPT) 

34 and 4 

-- 

SECURITY REQUIRED(NONE) 

34 

— 

SECURITY REQUIRED(CONVERSATION) 

34 and 6 

— 

SECURITY REQUIRED(ACCESS(PROFILE)) 

34 and 9 

— 

SECURITY_REQUIRED(ACCESS(USER ID)) 

34 and 8 

-- 

SECURITY_REQUIRED(ACCESS(USER_ID_PROFILE)) 

34, 8 and 

Q 

— 

SECURITY ACCESS(ADD(USER ID(variable) 

34 and 8 

_ 

PROFILE(variable))) 

34 and 9 

— 

SECURITY_ACCESS(DELETE(USER ID(variable) 

34 and 8 

— 

PR0FILE(variable))) 

34 and 9 

— 

PIP(NO) 

34 

— 

PIP(YES(variable)) 

34 and 12 

— 

DATA MAPPING(NO) 

34 

-- 

DATA MAPPING(YES) 

34 and 22 

— 

FMH DATA(NO) 

34 

— 

FMH DATA(YES) 

34 and 23 

-- 

PRIVILEGE(NONE) 

34 

— 

PRIVILEGE(CNOS) 

34 

— 

PRIVILEGE(SESSION_CONTROL) 

34, and 

— 


32 or 33 


PRIVILEGE(DEFINE) 

34 

— 

PRIVILEGE(DISPLAY) 

34 

— 

PRIVILEGE(ALLOCATE SERVICE TP) 

34 

— 

RETURN_CODE 

34 

— 

DISPLAY_LOCAL_LU 

34 

— 

FULLY QUALIFIED LU NAME 

34 

-- 

RETURN CODE 

34 

— 

LU_SESSION_LIMIT 

34 

— 

LU SESSION_COUNT 

34 

— 

SECURITY 

34 and 6 

— 

MAP NAMES 

34 

— 

REMOTE_LU_NAMES 

34 

— 

TP_NAMES 

34 

—— 

DISPLAY REM0TE_LU 

34 

— 

FULLY_QUALIFIED LU NAME 

34 

-- 

RETURN CODE 

34 

— 

LOCALLY KNOWN LU NAME 

34 and 36 

— 

UNINTERPRETED LU NAME 

34 and 37 

— 

INITIATE TYPE 

34 

— 

PARALLEL SESSION SUPPORT 

34 

— 

CNOS SUPPORT 

34 

— 

SECURITY ACCEPTANCE LOCAL LU 

34 and 6 

— 

SECURITY ACCEPTANCE REMOTE LU 

34 and 6 

— 

MODE NAMES 

34 

—— 


Figure A-13. Support for Control Operator Verbs and Parameters for LU Definition 
(Part 2 of 3) 
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Verb and Parameter 

Local Support 

Remote Support 

DISPLAY MODE 

34 

— 

FULLY QUALIFIED_LU NAME 

34 

— 

MODE NAME 

34 

— 

RETURN CODE 

34 

-- 

SEND PACING WINDOW 

34 

— 

RECEIVE PACING WINDOW 

34 

— 

SEND MAX RU SIZE_LOWER BOUND 

34 and 39 

— 

SEND MAX_RU SIZE_UPPER BOUND 

34 and 39 

— 

RECEIVE MAX RU_SIZE LOWER BOUND 

34 and 39 

— 

RECEIVE MAX RU SIZE UPPER BOUND 

34 and 39 

— 

SYNC LEVEL SUPPORT 

34 

— 

SINGLE SESSION_REINITIATION 

34 and 38 

— 

SESSION LEVEL CRYPTOGRAPHY 

34 and 40 

— 

CONWINNER AUTO ACTIVATE LIMIT 

34 and 41 

-- 

LU MODE SESSION LIMIT 

34 

— 

MIN_CONWINNERS 

34 

— 

MIN CONLOSERS 

34 

— 

TERMINATION COUNT 

34 

— 

DRAIN LOCAL LU 

34 

— 

DRAIN REMOTE LU 

34 

-- 

LU MODE SESSION COUNT 

34 

— 

CONWINNERS_SESSION_COUNT 

34 

— 

CONLOSERS SESSION COUNT 

34 

— 

SESSION_IDS 

34 

—— 

DISPLAY TP 

34 

—— 

TP NAME 

34 

— 

RETURN CODE 

34 

— 

STATUS 

34 

— 

CONVERSATION TYPE 

34 

— 

SYNC LEVEL 

34 

— 

SECURITY_REQUIRED 

34 and 6 

— 

SECURITY_ACCESS 

34, and 

— 


8 or 9 


PIP 

34 and 12 

— 

DATA MAPPING 

34 and 22 

— 

FMH DATA 

34 and 23 

— 

PRIVILEGE 

34 

—— 

DELETE 

34 

_ 

LOCAL LU NAME 

34 ! 

— 

REMOTE LU NAME 

34 

— 

MODE NAME 

34 

-- 

TP NAME 

34 

-- 

RETURN CODE 

34 

—— 


Figure A-14. Support for Control Operator Verbs and Parameters for LU Definition 
(Part 3 of 3) 
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SUPPORT FOR CONTROL-OPERATOR RETURN CODES 


Return Code 

Local Support 

ACTIVATION_FAILURE_NO_RETRY 

32 

ACTIVATION_FAILURE_RETRY 

32 

ALLOCATION ERROR 

B 

ALLOCATION FAILURE NO RETRY 

B 

ALLOCATION_FAILURE RETRY 

B 

TRANS_PGM_NOT_AVAIL_RETRY 

B 

COMMAND_RACE_REJECT 

B 

LU_MODE_SESSION_LIMIT„CLOSED 

B 

LU_MODE_SESSION_LIMIT_EXCEEDED 

32 

LU_MODE_SESSION_LIMIT_NOT_ZERO 

B 

LU_M0DE_SESSI0N_LIMIT_ZER0 

27 

LU_SESSION_LIMIT_EXCEEDED 

B 

OK 

B 

AS SPECIFIED 

B 

AS_NEGOTIATED 

B 

FORCED 

31 

PARAMETER_ERROR 

B 

REQUEST_EXCEEDS_MAX_ALLOWED 

B 

RESOURCE_FAILURE_NO_RETRY 

B 

UNRECOGNIZED_MODE_NAME 

B 


Figure A-15. Support for Control Operator Return Codes 
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NOTES OH IMPLEMENTATION DETAILS 


The following notes pertain to the base and optional support shown in 

the preceding figures. These notes describe certain implementation 

details* which are product dependent. 

Notes that AppIv to Conversation Verbs: 

1. The MC_ALLOCATE and ALLOCATE verbs send an allocation request to 
the remote LU. The remote LU starts the transaction program named 
in the allocation request. As this function is described in this 
book* the remote LU starts a new execution instance of the named 
transaction program. All products support this capability. A 
product may* in addition* allow an already-executing instance of 
the named transaction program to receive an allocation request by 
means of a product-dependent verb. This product-dependent capa¬ 
bility provides no means in the LU for correlating the new conver¬ 
sation to a previous one. 

2. The RETURN_CONTROL parameter on the MC_ALLOCATE and ALLOCATE 
verbs specifies when local processing of the verb is to be com¬ 
pleted* in terms of the allocation of a session for the conversa¬ 
tion. A product may provide for the specification of additional 
conditions for allocating sessions* such as a variation of the 
argument WHEN_SESSION_ALLOCATED that omits contention-loser ses¬ 
sions from the selection process. 

3. Products that provide local support for option set 6 

(conversation-level security verification) but not option set 7 
(program supplied user ID and password) may choose to not make the 
SECURITY parameter on the MC_ALLOCATE and ALLOCATE verbs explic¬ 
itly available to their transaction programs. Such products 
implicitly support both SECURITY(SAME) and SECURITY(NONE) in that 
they downgrade SECURITY(SAME) to SECURITY(NONE) when the remote 
LU does not accept conversation-level security* or the already- 
verified indication* from the local LU. 

4. Support of the PIP parameter on the MC_ALLOCATE and ALLOCATE verbs 
is optional and local support is independent of remote support. A 
product may provide either local or remote support* or both. 

5. The MC_POST_ON_RECEIPT and P0ST_0N_RECEIPT verbs* as described in 
this book* may be issued for a given conversation any number of 
times before posting is reset or cancelled. (See the notes under 
the descriptions of the verbs for more details.) However* a prod¬ 
uct may* instead* permit the verbs to be issued only once for a 
given conversation and disallow subsequent use of the verbs on 
that conversation until posting is reset or cancelled. 

6. The MC_R EC El V E_A N D_W AIT and RECEIVE_ANDJ4AIT verbs are used to 
wait until the requested amount of data or other information is 
available for the program to receive* receive the data or other 
information* and then resume program execution. Rather than 
resuming program execution as soon as the requested amount of data 
is received* the product may defer resuming program execution 
until it receives something other than data* such as a SEND* CON¬ 
FIRM* TAKE_SYNCPT, or DEALLOCATE indication. 

7. The WHAT_RECEIVED parameter on the MC_RECEIVE_AND_WAIT* 
MC_RECEIVE_IMMEDIATE* RECEIVE_ANDJ4AIT* and RECEIVE_IMMEDIATE 
verbs returns to the transaction program only one indication at a 
time. This serialization of returning what-received indications 
to the program results in discrete states of the conversation for 
each returned indication. (See the verb descriptions in this book 
for the state changes that can occur.) A product may* instead* 
return more than one indication at a time. For example* the prod¬ 
uct may return indications for both DATA and SEND at the com¬ 
pletion of the verbs. In this case* the state changes that occur 
at the completion of the verbs may differ from that described in 
this book. Refer to the product f s publication for further 
detaiIs. 

8. The MC_REQUEST_TO_SEND and REQUEST_TO_SEND verbs* as described in 
this book* may be issued only when the conversation is in receive* 
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confirm, or sync point state. Issuing the verbs for a conversa¬ 
tion in any other state is described as a state-check ABEND condi¬ 
tion. As an alternative to the ABEND condition, a product may 
also permit its transaction programs to issue the verbs for con¬ 
versations in send or defer state. 

9. The REQUEST TO_SEND_RECEIVED parameter on the 

MC_RECEIVE_ANDJ4AIT, MC_RECEIVE_IMMEDIATE, RECEIVE_AND_WAIT, and 
RECEIVE__IMMEDIATE verbs is used to receive a request-to-send 
notification when the conversation is in receive state. (See the 
notes under the descriptions of these verbs for details of uihen 
this can occur.) However, a product may defer passing the 
request-to-send notification to the program until the program 
issues an MC_SEND_DATA or SEND_DATA verb, or issues an 
MC_SEND_ERROR or SEND^ERROR verb when the conversation is in send 
state. 

Also, a product that defers passing the request-to-send notifica¬ 
tion to the program may discard the notification, and not pass it 
to the program, if the program issues an MC_PREPARE_TO_RECEIVE or 
PREPARE_TO_RECEIVE verb, issues an MC_RECEIVE_AND_WAIT or 
RECEIVE_AND_WAIT verb when the conversation is in send state, or 
receives a PROG_ERROR_PURGING or SVC_ERROR_PURGING return code 
when the conversation is in send state. 

Notes that AppIv Only to Mapped Conversation Verbs: 

10. A base local and remote support is defined for the data record 

length specified by the LENGTH parameter on the 

MC_POST_ON_RECEIPT, MC_RECEIVE_ANDJ4AIT, MC_RECEIVE — IMMEDIATE, 
and MC_SEND_DATA verbs. The base support for the data record 
length is 2048. All transaction programs are allowed to send and 
receive data records up to 2048 bytes in length. Local and remote 
support for data records greater than 2048 bytes in length is 
optional, and the maximum length is product-dependent. 

11. The MAP_NAME parameter on the MC_SEND_DATA verb is used to specify 
data mapping. MAP_NAME(NO) yields a null value for the map name, 
which suppresses data mapping, whereas MAP_NAME(YES(variable)) 
specifies a non-null map name, which invokes data mapping. Pro¬ 
ducts that support option set 22 (data mapping) provide local and 
remote support for both MAP_NAME(NO) and MAP_NAME(YES(variable)). 
However, a product may provide local support only for 
MAP_NAME(YES(variable)) on MC_SEND_DATAs issued on conversations 
that use data mapping. 

12. The FMH_DATA(YES) parameter on the MC_SEND_DATA verb specifies 
that the data record contains FM header data. Transaction pro¬ 
grams written for a product that implements LU 6.1 make use of the 
specification of FM header data. A product that implements LU 6.2 
may provide local and remote support for this parameter, either 
because it processes LU 6.1 programs or because it processes LU 
6.2 programs that connect to LU 6.1 programs. 

13. The what-received indications, DATA_TRUNCATED and 

FMH_DATA_TRUNCATED, inform the program that it received only part 
of the data record and the LU has discarded the remaining part. A 
product may, instead, retain the remaining data and indicate 
DATA_INCOMPLETE or FMH_DATA_INCOMPLETE. Alternatively, the prod¬ 
uct may support both capabilities and allow the program to select 
whether the LU i s to discard or retain remaining data. 

Notes that AppIv only to Basic Conversation Verbs: 

14. The TYPE(ABEND_SVC) and TYPE(ABEND_TIMER) parameters on the DEAL¬ 
LOCATE verb and the TYPE(SVC) parameter on the SEND_ERROR verb are 
used to indicate errors that the mapped conversation LU services 
component detects. A product that does not support option set 26 
(mapped conversation LU services component) may, nevertheless, 
support these parameters at its basic conversation protocol 
boundary. 

15. The L0G_DATA parameter on the DEALLOCATE and SEND_ERROR verbs is 
used to record product-unique error information in the system 
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error logs of the local and remote LUs. The capability to receive 
the log data is part of the base remote support. However* a prod¬ 
uct that does not provide local support for option set 13 (logging 
of data in a system log) may discard the received log data rather 
than process it. 

16. The FILL parameter on the P0ST_0N_RECEIPT, RECEIVE_ANDJ4AIT, and 
RECEIVE_INMEDIATE verbs has two arguments: LL and BUFFER. A prod¬ 
uct may support only one of the arguments* or it may support both 
of them. 

The arguments are described in this book as being independent of 
each other; that is* the specification of either one does not 
depend on the past use of the parameter* and has no bearing on its 
subsequent use. A product supporting both arguments may treat 
them as described* or it may treat them in a dependent manner* 
allowing the program to specify only one or the other for certain 
sequences of the verbs and indicating an error if this restriction 
is violated. 

17. The what-received indication* LL_TRUNCATED* informs the program 
that the LU received only the first byte of the LL field of a log¬ 
ical record* because it was truncated. The truncated LL field is 
discarded by the receiving LU rather than being passed to the 
receiving program. A product may* instead* pass the truncated LL 
field to the program and indicate DATA_INCOMPLETE rather than 
LL_TRUNCATED. 

Notes that AppIv to Control-Operator Verbs? 

18. A product may provide local (source LU) support for only one of 
the arguments, NO or YES* of the DRAIN_SOURCE parameter on the 
RESET_SESSION_LIMIT verb, or it may support both arguments. How¬ 
ever* all products provide remote (target LU) support for both 
arguments. 

19. Remote support for the RESPONSIBLE(TARGET) parameter of the 
CHANGE_SESSION_LIMIT and RESET_SESSION_LIMIT verbs is part of the 
base set of functions. However* a product may provide remote sup¬ 
port for this parameter by always negotiating the TARGET argument 
to SOURCE during its remote processing* as a target LU* of 
CHANGE_SESSION_LIMIT and RESET_SESSION_LIMIT. 

20. Remote support for the DRAIN_TARGET(YES) parameter of the the 
RESET_$E5SI0N_LIMIT verb is part of the base set of functions. 
However* a product may provide remote support for this parameter 
by always negotiating the YES argument to NO during its remote 
processing* as a target LU* of RESET_SESSION_LIMIT. 

21. A product may allow the control operator or transaction program to 
specify certain parameters of the DEFINE_MODE verb by means of the 
DEFINEJLOCALJ.U or DEFINE_REM0TE_LU verb, instead. These parame¬ 
ters are: 

SYNC LEVEL_SUPPORT 

SINGLE_SESSION_REINITIATION 

SESSIONJ.EVEL_CRYPTQGRAPHY 

When these parameters are specified by means of DEFINE_LOCAL_LU* 
the local LU f s corresponding operating parameters are constant 
across all mode names for all remote LUs. Similarly* when these 
parameters are specified by means of DEFINE_REMOTE_LU* the local 
LU f s corresponding operating parameters are constant across all 
mode names for a given remote LU* but they may differ for each 
remote LU. 
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APPENDIX B. EXAMPLES USING BASIC CONVERSATION VERBS 


This appendix contains examples of the use of some of the basic con¬ 
versation verbs. Each example shows two transaction programs, TP(a) 
and TP(b), connected by a conversation. The letters a and b represent 
each program’s name. 

Each example concentrates on the use of one, two or three verbs, in 
conjunction with several other verbs, and how the verbs issued by one 
program relate to the verbs issued by the other program. When a verb 
causes the LU to send information to the other program, the resulting 

flow is shown as an arrow C->). Some verbs cause the LU to suspend 

the program’s processing until the LU completes execution of the verb; 
a vertical line (|) under the verb indicates the suspension of program 
processing. 

Some parameters are shown with the verbs. The parameters shown are 
those that are significant to the example. Supplied parameters are 
shown as ”parameter-name(supplied-value),” and returned parameters 
are shown as ”parameter-name=returned-value. n Parameters not signif¬ 
icant to the example are not shown. 

On the page facing the example are notes that explain what the example 
is illustrating. The notes are numbered. The part of the example to 
which the note applies is keyed with the same number, shown within 
braces. For instance, the part of the example in Figure B-l on page 
B-2 that is keyed by ”{1J” is explained by note 1 on the facing page. 

The examples contain a few comments, which are shown within brackets. 
For example, the comment, ”[TP(a) running],” in Figure B-l on page B-2 
means the program is already processing at the point the example 
begins. 


Appendix B. Examples Using Basic Conversation Verbs B-l 


[TP(a) running] 


ALLOCATE U) 

TPN(’b’) 

SYNC LEVELCNONE) (2} 
RETURN CODE=OK {3J 


SEND.DATA (4J 
RETURN CODE=OK 


DEALLOCATE (5) 

TYPE< SYNC_LEVEL) 

RETURN CODE=OK {6} -> [start TP(b)] «} 


[end conversation] {7} RECEIVE_AND_WAIT {9J 

RETURN_C0DE=0K 

WHAT_RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT tlOJ 

RETURN_CODE=DEALLOCATE_NORMAL 


DEALLOCATE {11} 
TYPE(LOCAL) 
RETURN_C0DE=0K 


[end conversation] [12) 


Figure B-l. ALLOCATE, SEND_DATA, DEALLOCATE — SYNC_LEVEL(NONE) 
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Notes for Figure B-l: 

1. TP(a) issues ALLOCATE to request a 
conversation with partner program 
'fa*, designated by the TPN parame¬ 
ter, 

2. The SYNC — LEVELCNONE) parameter 
specifies a synchronization level 
of NONE, which means no confirma¬ 
tion or sync point processing. 

3. The LU places the allocation 
request in its send buffer and 
returns control to TP(a) with the 
conversation in send state. Noth¬ 
ing is sent. 

4. TP(a) issues SEND_DATA, causing the 
LU to place the data (a logical 
record) in its buffer behind the 
allocation request. Still, nothing 
is sent, because the LU does not 
yet have a sufficient amount of 
information for transmission (in 
this example). 

5. TP(a) issues DEALLOCATE with 
TYPE(SYNC — LEVEL), which implies no 
synchronization and causes the LU 
to send the contents of its buffer 


together with a DEALLOCATE_NORMAL 
indication. 

6. Because the synchronization level 
is NONE, DEALLOCATE with 

TYPECSYNC_LEVEL) completes imme¬ 
diately and successfully. Contrast 
this with Figure B-2 on page B-4. 

7. The conversation is deallocated 
from the session at the completion 
of DEALLOCATE. 

8. TP(b) is started, with the conver¬ 
sation in receive state, when its 
LU receives the allocation request. 

9. TP(b) issues RECEIVE_AND_WAIT and 
receives the complete logical 
record. 

10. TP(b) issues another 
RECEIVE_AND WAIT and receives the 
DEALLOCATE_NORMAL indication. 

11. TP(b) issues DEALLOCATE with 
TYPE(LQCAL), causing the LU to dis¬ 
card its control information for 
the conversation. 

12. The conversation ends for TPCb). 
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CTP(a) running] 


ALLOCATE LI) 

TPN('b') 

SYNCJ.EVEL(CONFIRM) {2J 
RETURN_CODE-OK {31 


SEND_DATA L4J 
RETURN_CODE=OK 


DEALLOCATE {5} 
TYPE(SYNC_L EVEL) 
I (6) 


> [start TP(b)3 {7} 


RECEIVE_AHD_WAIT (8J 
RETURN_CODE=OK 
WHAT_RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT [9J 
RETURN_CODE=OK 
WHAT_RECEIVED=CONFIRM_ 

DEALLOCATE 


RETURN_CODE=OK {111 


CONFIRMED UOJ 


[end conversation] [12] 


DEALLOCATE [13) 
TYPE(LOCAL) 
RETURN_CODE=OK 


[end conversation] {14} 


Figure B-2. ALLOCATE, SEND_DATA, DEALLOCATE — SYNC_LEVEL(CONFIRM) 
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Notes for Figure B-2: 

1. TPCa) issues ALLOCATE to request a 
conversation with partner program 
•b*. 

2. The SYNC_LEVEL(CONFIRM) parameter 
specifies a synchronization level 
of CONFIRM, which means confirma¬ 
tion processing is permitted* 

3. The LU places the allocation 
request in its send buffer and 
returns control to TP(a) with the 
conversation in send state* Noth¬ 
ing is sent. 

4. TPCa) issues SEND_DATA, causing the 
LU to place the data (a logical 
record) in its buffer behind the 
allocation request. Still, nothing 
is sent. 

5. TP(a) issues DEALLOCATE with 
TYPE($YNC_LEVEL), which implies 
confirmation processing and causes 
the LU to send the contents of its 
buffer together with a CON- 
FIRM_DEALLOCATE request. 

6. Because the synchronization level 
is CONFIRM, DEALLOCATE with 
TYPE(SYNC_LEVEL) causes the LU to 
suspend TP(a) f s processing until it 
receives a response, affirmative or 
negative. 


7. TP(b) is started, with the conver¬ 
sation in receive state, when its 
LU receives the allocation request. 

8. TP(b) issues RECEIVE_AND_WAIT and 
receives the complete logical 
record. 

9. TP(b) issues another 
RECEIVE_AND_WAIT and receives the 
CONFIRM_DEALLOCATE request. 

10. TPCb) responds affirmatively by 
issuing CONFIRMED, causing its LU 
to send a positive response. If 
TPCb) responded negatively by issu¬ 
ing SEND — ERROR (not shown), the 
conversation would remain allo¬ 
cated. 

11. The LU returns control to TP(a), 
indicating an affirmative response 
and successful completion of the 
DEALLOCATE. 

12. The conversation is deallocated 
from the session at the completion 
of DEALLOCATE. 

13. TPCb) issues DEALLOCATE with 
TYPECLOCAL), causing the LU to dis¬ 
card its control information for 
the conversation. 

14. The conversation ends for TPCb). 
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tTP(a) running & 
in conversation] {1} 


[TP(b) running & 
in conversation] 


SEND_DATA {2} 
RETURN CODE-OK 


RECEIVE ANDWAIT {3} 


RECEIVE AND WAIT {4} 


-> RETURN C0DE=0K 15) 

WHAT RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT t6> 
RETURN_CODE=OK 
WHAT RECEIVED=SEND 


SEND DATA t7J 
RETURN_CODE=OK 


RETURN_CODE=OK {10} <- 

WHAT_RECEIVED=DATA COMPLETE 


DEALLOCATE {8} 

TYP E(SYNC_L EV EL) 
I (9) 


RECEIVE_AND_WAIT til) 
RETURN_CODE=OK 

WHAT_RECEIVED=CONFIRM_DEALLOCATE 


CONFIRMED U2J 


-> RETURN CODE=OK {13} 


DEALLOCATE {15} 
TYPE(LOCAL) 
RETURN_CODE=OK 


lend conversation] {14} 


[end conversation] {16} 


Figure B-3. RECEIVE_AND_WAIT, DEALLOCATE -- SYNC_LEVELCCONFIRM) 
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Notes for Figure B-3: 

1. Assume TP(a) has already allocated 
the conversation with 

SYNC_LEVEL(CONFIRM), and the con¬ 
versation is now in send state for 
TP(a) and receive state for TP(b). 

2. TP(a) issues SEND_DATA, causing the 
LU to place the data (a logical 
record) in its buffer* Nothing is 
sent. 

3. TP(b) issues RECEIVE_AND_WAIT, 
causing the LU to suspend TP(b) T s 
processing until it receives infor¬ 
mation . 

4. TP(a) issues RECEIVE_AND_WAIT, 
causing the LU to send the contents 
of its buffer together with the 
SEND indication. The LU suspends 
TP(a)'s processing until it 
receives information. 

5. The LU returns control to TP(b), 
indicating that the program has 
received the complete logical 
record. 


confirmation processing and causes 
the LU to send the contents of its 
buffer together with a CON- 
FIRM_DEALLOCATE request. 

9. Because the synchronization level 
is CONFIRM, DEALLOCATE with 
TYPEC SYNC_LEVEL) causes the LU to 
suspend TP(b) f s processing until it 
receives a response, affirmative or 
negative. 

10. The LU returns control to TP(a), 
indicating that the program has 
received the complete logical 
record. 

11. TP(a) issues another 
RECEIVE_AND_WAIT and receives the 
CONFIRM_DEALLOCATE request. 

12. TP(a) responds affirmatively by 
issuing CONFIRMED, causing its LU 
to send a positive response. 

13. The LU returns control to TP(b), 
indicating an affirmative response 
and successful completion of the 
DEALLOCATE. 


6. TP(b) issues another 

RECEIVE_AND_WAIT and receives the 
SEND indication. 


7. TP(b) issues SEND_DATA, causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent. 


8. TP(b) issues DEALLOCATE with 

TYPE(SYNC_LEVEL), which implies 


14. The conversation is deallocated 
from the session at the completion 
of DEALLOCATE. 

15. TP(a) issues DEALLOCATE with 
TYPE(LOCAL), causing the LU to dis¬ 
card its control information for 
the conversation. 

16. The conversation ends for TP(a). 
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ITPta) running & 
in conversation] {1} 


tTP(b) running 4 
in conversation] 


SEND DATA {2J RECEIVE_AND_WAIT {31 

reTurn_code=ok | 


PREPARE_TO_RECEIVE {4) 

TYPE(SYNC LEVEL) | 

RETURN_C0DE=0K {5} -> RETURN_C0DE=0K 17) 

WHAT RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT L6J 


RECEIVE AND.WAIT 18) 
RETURN_CODE=OK 
WHAT RECEIVED=SEND 


SEND_DATA {9} 


Figure B-4. PREPARE_TO_RECEIVE — SYNC_LEVELCNONE) 
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Notes for Figure B-4: 

1. Assume TP(a) has already allocated 
the conversation with 
SYNC_LEVELCNONE), and the conversa¬ 
tion is now in send state for TPCa) 
and receive state for TPCb). 

2. TPCa) issues SEND_DATA, causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent. 

3. TPCb) issues RECEIVE_AND_WAIT, 
causing the LU to suspend TPCb)'s 
processing until it receives infor¬ 
mation. 

4. TPCa) issues PREPARE..TO RECEIVE 
with TYPECSYNCJ.EVEL), which 
implies no synchronization and 
causes the LU to send the contents 
of its buffer together with the 
SEND indication. 


5. Because the synchronization level 
is NONE, PREPARE_TO_RECEIVE with 
TYPECSYNC_LEVEL) completes imme¬ 
diately and successfully. Contrast 
this with Figure B-5 on page B-10. 

6. The conversation for TPCa) is now 
in receive state, so TPCa) issues a 
RECEIVE_AND_WAIT. 

7. The LU returns control to TPCb), 
indicating that the program has 
received the complete logical 
record. 

8. TPCb) issues another 
RECEIVE_AND_WAIT and receives the 
SEND indication. 

9. The conversation for TPCb) is now 
in send state, so TPCb) issues a 
$END_DATA. 
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tTP(a) running & 
in conversation] {1J 


ITP(b) running & 
in conversation] 


SEND_DATA {2} 
RETURN_C0DE=0K 


PREPARE_TO_RECEIVE {4} 
TYPE(SYNC LEVEL) 

I (5 J 


RETURN C0DE=0K {10} 


RECEIVE_AND_WAIT {3} 


> RETURN_C0DE=0K {6} 

WHAT RECEIVED=DATA_COMPlETE 


RECEIVE_AND_WAIT C7J 
RETURN_CODE=OK 
WHAT RECEIVED=CONFIRM_SEND 


<- CONFIRMED (8) 


RECEIVE_AND_WAIT {11} 


SEND DATA {9} 


Figure B-5. PREPARE_TO_RECEIVE -- SYNC_LEVEL(CONFIRM) 
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Notes for Figure B-5: 

1. Assume TP(a) has already allocated 
the conversation with 
SYNC_LEVEL(CONFIRM), and the con¬ 
versation is now in send state for 
TP(a) and receive state for TPCb). 

2. TP(a) issues SEND_DATA, causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent, 

3. TPCb) issues RECEIVE_AND_WAIT, 
causing the LU to suspend TP(b)*s 
processing until it receives infor¬ 
mation, 

4. TPCa) issues PREPARE_TO_RECEIVE 
with TYPE(SYNC_LEVEL), which 
implies confirmation processing and 
causes the LU to send the contents 
of its buffer together with the 
CONFIRM^SEND request. 

5. Because the synchronization level 
is CONFIRM, PREPARE_TO RECEIVE with 
TYPEC SYNC_LEVEL) causes the LU to 
suspend TP(a) f s processing until it 


receives a response, affirmative or 
negative. 

6. The LU returns control to TPCb), 
indicating that the program has 
received the complete logical 
record. 

7. TPCb) issues another 

RECEIVE_AND_WAIT and receives the 
CONFIRM_SEND request. 

8. TPCb) responds affirmatively by 
issuing CONFIRMED, causing its LU 
to send a positive response. 

9. The conversation for TPCb) is now 
in send state, so TPCb) issues a 
SEND_DATA. 

10. The LU returns control to TPCa), 
indicating an affirmative response 
and successful completion of the 
PREPARE_TO_RECEIVE. 

11. The conversation for TPCa) is now 
in receive state, so TPCa) issues a 
RECEIVE_AND WAIT. 
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CTP(a) running & 
in conversation] {1} 


[TPCb) running S 
in conversation] 


SEND DATA {2} 

reTurn_code=ok 

CONFIRM 

RETURN_C0DE=0K t9J 


RECEIVE_AND_WAIT 

{3) 

RETURN C0DE=0K 

{5J 

WHAT_RECEIVED= 

DATA_COMPLETE 

RECEIVE_AND_WAIT 

{6J 


RETURN_CODE=OK 

WHAT_RECEIVED=CONFIRM 

<- CONFIRMED {71 


SEND_DATA UOJ 


RECEIVE AND_WAIT {81 


Figure B-6. CONFIRM 
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Notes for Figure B-6: 

1. Assume TP(a) has already allocated 
the conversation with 

SYNC^LEVEL(CONFIRM)# and the con¬ 
versation is now in send state for 
TP(a) and receive state for TP(b). 

2. TP(a) issues SEND_DATA# causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent. 

3. TP(b) issues RECEIVE_AND_WAIT# 
causing the LU to suspend TP(b) f s 
processing until it receives infor¬ 
mation. 

4. TP(a) issues CONFIRM in order to 
synchronize the processing of the 
two programs. The CONFIRM verb 
causes the LU to send the contents 
of its buffer together with the 
CONFIRM request. The LU suspends 
TP(a) f s processing until it 
receives a response# affirmative or 
negative. 


5. The LU returns control to TP(b)# 
indicating that the program has 
received the complete logical 
record. 

6. TP(b) issues another 
RECEIVE_AND — WAIT and receives the 
CONFIRM request. 

7. TP(b) responds affirmatively by 
issuing CONFIRMED# causing its LU 
to send a positive response. 

8. The conversation for TP(b) is still 
in receive state# so TP(b) issues 
another RECEIVE_AND_WAIT. 

9. The LU returns control to TP(a)# 
indicating an affirmative response 
and successful completion of the 
CONFIRM. 

10. The conversation for TP(a) is still 
in send state# so TP(a) issues 
another SEND _DATA. 
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CTP(a) running & 
in conversation] tlJ 


ETP(b) running & 
in conversation] 


SEND_DATA {2} 
RETURN_C0DE=0K 


RECEIVE_AND_MAIT {3J 


SEND_ERROR W 


-> RETURN_CODE=OK T7J 

WHAT_RECEIVED=DATA_COMPLETE 


RETURN C0DE=0K T5J 


RECEIVE_AND_WAIT {8J 
-> RETURN_C0DE=PR0G_ERR0R_N0_ 
TRUNC 


SEND_DATA {6J 


RECEIVE ANDWAIT {9} 


Figure B-7. SEND_ERROR in Send State 
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Notes for Figure B-7: 

1. Assume TP(a) has already allocated 
the conversation and it is now send 
state for TP(a) and receive state 
for TP(b). 

2. TP(a) issues SEND_DATA, causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent. 

3. TP(b) issues RECEIVE_AND_WAIT, 
causing the LU to suspend TPCb)*s 
processing until it receives infor¬ 
mation. 

4. TP(a) issues SEND_ERROR in order to 
notify the partner program of an 
error. The SEND^ERROR verb causes 
the LU to send the contents of its 
buffer. 

5. After sending the contents of its 
buffer, the LU sends the error 


notification and returns control to 
the program. 

6. The conversation for TP(a) is still 
in send state, so TP(a) issues 
another SEND_DATA, possibly con¬ 
taining additional error-recovery 
information. 

7. The LU returns control to TPCb), 
indicating that the program has 
received the complete logical 
record. 

8. TPCb) issues another 
RECEIVE_AND_WAIT and receives the 
error notification, 
PROG_ERROR_NO_TRUNC, meaning TP(a) 
issued a SEND_ERRQR that did not 
truncate the logical record it 
sent. 

9. The conversation for TPCb) is still 
in receive state, so TPCb) issues 
another RECEIVE_AND_WAIT. 
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tTP(a) running & 
in conversation] {1} 


tTP(b) running & 
in conversation] 


SEND DATA {2} 
RETURN CODE-OK 


RECEIVE_AND_WAIT {3} 


SEND DATA (4) 
RETURN_C0DE=0K 


-> RETURN_CODE=OK (5J 

WHAT_RECEIVED=DATA_COMPLETE 


{7J <- 


SEND_ERROR UJ 


SEND_DATA {8} 


RETURN_CODE=PROG_ERROR 

PURGING TllJ 


RETURN CODE=OK C9J 


RECEIVE_AND_WAIT {12} 


SEND_DATA {10} 


Figure B-8. SEND_ERROR in Receive State 
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Notes for Figure B-8: 

1. Assume TP(a) has already allocated 
the conversation and it is now send 
state for TP(a) and receive state 
for TP(b). 

2. TP(a) issues SEND.DATA, causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent. 

3. TP(b) issues RECEIVE.AND_.WAIT, 
causing the LU to suspend TP(b) ? s 
processing until it receives infor¬ 
mation. 

4. TP(a) issues another SEND.DATA, 
causing the LU to place the data 
(another logical record) in its 
buffer. The LU now has more than 
enough data for transmission, so it 
sends some of the contents of its 
buffer, and retains the remainder 
for later transmission. 

5. The LU returns control to TP(b), 
indicating that the program has 
received a complete logical record. 

6. TP(b) issues SEND.ERRQR in order to 
notify the partner program of an 
error. The SEND.ERROR verb causes 
the LU to purge information it has 
received and not yet passed to 
TP(b), and to send a negative 


response. The LU then suspends 
TP(b) v s processing awaiting the 
receipt of SEND control. 

7. The LU for TP(a) receives the nega¬ 
tive response, causing it to purge 
the remaining contents of its buff¬ 
er. 

8. TPCa) issues SEND.DATA. The 
SEND.DATA is unsuccessful — the LU 
does not place the data in its 
buffer. The SEND.DATA causes the 
LU to send the SEND control without 
data. The LU then suspends TP(a) v s 
processing awaiting the receipt of 
the error notification. 

9. The LU for TP(b) receives the SEND 
control, sends the error notifica¬ 
tion, and returns control to TP(b). 

10. The conversation for TP(b) is now 
in send state, so TP(b) issues a 
SEND.DATA, possibly containing 
additional error-recovery informa¬ 
tion. 

11. The LU returns control to TP(a), 
indicating that it has received the 
error notification, 
PROG.ERROR.PURGING. 

12. The conversation for TP(a) is now 
in receive state, so TPCa) issues a 
RECEIVE_AND_WAIT. 
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tTP(a) running & 
in conversation] {1} 


tTP(b) running & 
in conversation] 


< 

SEND.DATA {4} 

RETURN__CODE=OK 

REQUEST_TO_SEND_RECEIVED=YES 


SEND_DATA {5} 
RETURN_C0DE=0K 


RECEIVE_AND_WAIT {6J -> RETURN_C0DE=0K C7> 

WHAT RECEIVED=DATA_COMPLETE 


RECEIVE_AND_WAIT (8J 
RETURN_CODE=OK 
WHAT_RECEIVED=DATA COMPLETE 


RECEIVE_AND_WAIT E9J 
RETURN_C0DE=0K 
WHAT_RECEIVED=SEND 


SEND_DATA UOJ 


REQUEST_TO_SEND 12} 
RECEIVE_AND_WAIT t3J 


Figure B-9. REQUEST_T0 SEND 
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Notes for Figure B-9: 

1. Assume TP(a) has already allocated 
the conversation and it is now send 
state for TP(a) and receive state 
for TPCb). 

2. TP(b) issues REQU ES T_T0_SEND and 
the LU sends the REQUEST_TO_SEND 
indication. The conversation for 
TP(b) remains in receive state 
because REQUEST_TG_SEND does not 
force a turnaround of SEND control. 
Contrast this with SEND_ERROR in 
Figure B-8 on page B-16. 

3. TP(b) issues RECEIVE_AND_WAIT# 
causing the LU to suspend TP(b) f s 
processing until it receives infor¬ 
mation . 

4. TPCa) issues SEND_DATA# causing the 
LU to place the data (a logical 
record) in its buffer# and indicate 
that it has received a 

REQUEST_T0_SEND indication. Noth¬ 
ing is sent. 

5. TPCa) issues another SEND__DATA# 
causing the LU to place the data 


(another logical record) in its 
buffer. The LU still does not have 
enough data for transmission# so 
nothing is sent. 

6. TPCa) issues RECEIVE_AND_WAIT, 
causing the LU to send the contents 
of its buffer together with the 
SEND indication. The LU suspends 
TP(a) f s processing until it 
receives information. 

7. The LU returns control to TPCb)# 
indicating that the program has 
received a complete logical record. 

8. TPCb) issues another 
RECEIVE__AND_WAIT and receives 
another complete logical record. 

9. TPCb) issues another 
RECEIVE_AND_WAIT and receives the 
SEND indication. 

10. The conversation for TPCb) is now 
in send state# so TPCb) issues a 
SEND_DATA. 
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TP(a) 


TP(b) 


[TP(b) running & 
in conversation] 


P0ST_0N_RECEIPT (2J 
RESOURCECCONV BA) 


P0ST_0H_RECEIPT {3} 
RESOURCE(CONVBC) 


WAIT {4J 

RESOURCES1ST(C0NV_BA 
CONV BC) 


RETURN_CODE=OK t5J 
RESOURCE POSTED=CONV_BC 


RECEIVE_AHD_WAIT {6} 
RESOURCE(CONV_BC) 
RETURN_CODE=OK 
WHAT_RECEIVED=DATA COMPLETE 


RECEIVE_AND_WAIT {7} 
RESOURCE(CONV_BA) 

SEHDDATA (81 I 


FLUSH 19} -> RETURN_CODE=OK UOJ 

WHAT RECEIVED=DATA_COMPLETE 


Figure B-10. POST_ON_RECEIPT, WAIT 


iTPta) running & 
in conversation] {1J 
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Notes for Figure B-10: 

1. Assume TP(a) has already allocated 
the conversation and it is nou in 
send state for TP(a) and receive 
state for TPCb). 

2. TPCb) issues POST_QN_RECEIPT for 
the conversation with TPCa). 

3. TPCb) issues another 
POST_ON_RECEIPT for the conversa¬ 
tion with TPCc), not shown. 

4. TPCb) then issues WAIT with a 
resource list specifying both con¬ 
versations. In this way, the pro¬ 
gram can receive the information on 
the conversation on which it 
arrives first. The WAIT causes the 
LU to suspend TPCb) f s processing 
until it receives information on 
either conversation. 

5. Information arrives on the conver¬ 
sation with TPCc). The LU resets 


the posting on that conversation 
and returns control to TPCb). 

6. TPCb) issues RECEIVE_AND_WAIT for 
the conversation with TPCc) and 
receives a complete logical record. 

7. TPCb) then issues RECEIVE_AND_WAIT 
for the conversation with TPCa), 
causing the LU to suspend TPCb) f s 
processing until it receives infor¬ 
mation on that conversation. 

8. TPCa) issues SEND_DATA, causing the 
LU to place the data Ca logical 
record) in its buffer. Nothing is 
sent. 

9. TPCa) issues FLUSH, causing the LU 
to send the contents of its buffer. 

10. The LU returns control to TPCb), 
indicating that the program has 
received a complete logical record. 
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tTP(a) running & 
in conversation] Cl) 


POST ON RECEIPT (21 


ITP(b) running 8 
in conversation] 


SEND_DATA (4J 


TEST {3J 

RETURN_CODE=UNSUCCESSFUL 


FLUSH (5J 


> L6J 


TEST (71 

RETURN_C0DE=0K 


RECEIVE_AND_WAIT (8) 
RETURN_CODE=OK 
WHAT RECEIVED=DATA_COMPLETE 


j Figure B-ll. P0ST_0N_RECEIPT, TEST 
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Notes for Figure B-U: 

1* Assume TP(a) has already allocated 
the conversation and it is now in 
send state for TP(a) and receive 
state for TPCb). 

2. TP(b) issues P0ST_0N_RECEIPT for 
the conversation with TPCa). 

3. TPCb) then issues TEST, which 
returns with 

RETURN_CODE=UNSUCCESSFUL indicating 
information is not available. 
Posting remains active and TPCb) 
continues processing. 

4. TP(a) issues 5END_DATA* causing the 
LU to place the data (a logical 


record) in its buffer. Nothing is 
sent. 

5. TP(a) issues FLUSH* causing the LU 
to send the contents of its buffer. 

6. Data arrives on the conversation* 
causing the LU to post the event. 

7. Some time later* TPCb) issues TEST 
again. This time it returns with 
RETURN_CODE=OK* and posting is 
reset. 

8. TPCb) issues RECEIVE_AND_WAIT for 
the conversation and receives a 
complete logical record. 
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Figure B-12. SYNCPT 
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Notes for Figure B-12: 

1* Assume TPCa) has already allocated 
the conversation with 
SYNC_LEVEL(SYNCPT)* and the conver¬ 
sation is now in send state for 
TP(a) and receive state for TP(b). 

2. Assume TP(b) has also allocated one 
or more conversations with 
SYNC.LEVELCSYNCPT) to other pro¬ 
grams. 

3. TP(a) issues SEND_DATA* causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent. 

A. TP(b) issues RECEIVEJVNDJdAIT, 

causing the LU to suspend TP(b) f s 
processing until it receives infor¬ 
mation. 

5. TP(a) issues SYNCPT in order to 
advance all protected resources 
throughout the distributed logical 
unit of work to the next synchroni¬ 
zation point. The LU suspends 
TP(a)*s processing until the sync 
point processing is complete. As 
part of the sync point processing* 
the LUs send and receive commands 
on the conversations* the commands 
are referred to in this example as 
a sync point request and reply. 
These commands are not apparent to 
the programs. 

6. The SYNCPT verb causes the LU to 
send the contents of its buffer 
together with the initial sync 
point request. 

7. The LU for TP(b) receives the data 
and sync point request. The LU 
returns control to TP(b)* indicat¬ 
ing that the program has received a 
complete logical record. 

8. TP(b) issues another 
RECEIVE_AND_WAIT and receives the 
TAKE_SYNCPT request* which is what 
the LU indicates to the program as 
a result of receiving the sync 
point request. 


9. TP<b) finishes processing of pro¬ 
tected local resources* if neces¬ 
sary* and ensures all other 
protected conversations are in send 
state. 

10. TPCb) issues SYNCPT* causing the LU 
to send the contents of its buffers 
(one for each conversation) togeth¬ 
er with a sync point request on all 
other protected conversations. The 
LU suspends TP(b) T s processing 
until a sync point reply is 
received on all these conversa¬ 
tions. 

11. After receiving sync point replies 
on all of the other protected con¬ 
versations* the LU for TPCb) sends 
a sync point reply on the conversa¬ 
tion on which it received the ini¬ 
tial sync point request. 

12. The LU returns control to TPCb) 
indicating successful completion of 
the SYNCPT for all protected 
resources allocated to TPCb) and 
all "down stream” TPs* that is* to 
all TPs other than TPCa). 

13. The conversation for TPCb) is still 
in receive state* so TPCb) issues 
another RECEIVE_AND_WAIT. 

14. The LU for TPCa) receives the final 
sync point reply and returns con¬ 
trol to TPCa) indicating successful 
completion of the SYNCPT for all 
protected resources throughout the 
distributed logical unit of work. 

15. The conversation for TPCa) is still 
in send state* so TPCa) issues 
another SENDJDATA. 

Note: More sync point commands may 
actually be exchanged between the par¬ 
ticipating LUs than the flows in this 
example indicate. See SNA Format and 
Protocol Reference Manual: Architec¬ 
ture Logic for LU Type 6.2 for details. 
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| Figure B-13. SYNCPT» BACKOUT 
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Notes for Figure B-13: 

1. Assume TP(a) has already allocated 
the conversation with 
SYNCJ.EVELCSYNCPT), and the conver¬ 
sation is now in send state for 
TP(a) and receive state for TPCb). 

2. Assume TPCb) has also allocated one 
or more conversations with 
SYNC_LEVEL CSYNCPT) to other pro¬ 
grams. 

3. TP(a) issues SEND_DATA* causing the 
LU to place the data (a logical 
record) in its buffer. Nothing is 
sent. 

4. TPCb) issues RECEIVE_ANDJ4AIT, 
causing the LU to suspend TPCb) f s 
processing until it receives infor¬ 
mation. 

5. TPCa) issues SYNCPT in order to 
advance all protected resources 
throughout the distributed logical 
unit of work to the next synchroni¬ 
zation point. The LU suspends 
TP(a) f s processing until the sync 
point processing is complete. As 
part of the sync point processing* 
the LUs send and receive commands 
on the conversations; the commands 
are referred to in this example as 
a sync point request and reply. 
These commands are not apparent to 
the programs. 

6. The SYNCPT verb causes the LU to 
send the contents of its buffer 
together with the initial sync 
point request. 

7. The LU for TPCb) receives the data 
and sync point request. The LU 
returns control to TPCb)* indicat¬ 
ing that the program has received a 
complete logical record. 

8. TPCb) issues another 
RECEIVE_AND_WAIT and receives the 
TAKE_$YNCPT request, which is what 
the LU indicates to the program as 
a result of receiving the sync 
point request* 

9. TPCb) finishes processing of pro¬ 
tected local resources* if neces¬ 
sary* and ensures all subordinate 
conversations are in send state. 

10. TPCb) issues SYNCPT* causing the LU 
to send the contents of its buffers 
Cone for each conversation) togeth¬ 
er with a sync point request on all 


other protected conversations. The 
LU suspends TPCb) f s processing 
until the sync point processing on 
all these conversations is com¬ 
plete. 

11. Instead of receiving sync point 
replies on all of the other pro¬ 
tected conversations* the LU for 
TPCb) receives at least one 
BACKED_OUT indication. The LU 
returns control to TPCb) with the 
BACKED_OUT indication. 

12. TPCb) issues BACKOUT* causing the 
LU to restore all protected local 
resources to the last synchroniza¬ 
tion point* and send BACKED_0UT 
indications on all protected con¬ 
versations except the oneCs) on 
which it received the preceding 
BACKED_QUT indication. BACKOUT is 
accomplished throughout the dis¬ 
tributed logical unit of work in 
the same manner as for TPCb). That 
is* the LU for each program 
receives a BACKED_0UT indication* 
returns control to its program with 
the BACKED_OUT indication* and then 
when the program issues BACKOUT it 
restores all protected local 
resources to the last synchroniza¬ 
tion point and sends BACKED_QUT 
indications on all remaining pro¬ 
tected conversations* if any. 

13. The LU for TPCa) receives the 
BACKED_OUT indication* sends back a 
positive response* and returns con¬ 
trol to TPCa) with the BACKED_OUT 

indication. 

14. TPCa) issues BACKOUT* causing the 
LU to restore all protected local 
resources to the last synchroniza¬ 
tion point. 

15. The conversation for TPCa) is 
restored to send state—the state 
at the completion of the last syn¬ 
chronization point—so TPCa) issues 
another SEND_DATA* possibly con¬ 
taining error-recovery information. 

16. The LU for TPCb) receives the posi¬ 
tive response from the LU for TPCa) 
and all other LUs to which it sent 
the BACKED_OUT indication* and 
returns control to TPCb). 

17. The conversation for TPCb) is 
restored to receive state—the 
state at the completion of the last 
synchronization point—so TPCb) 
issues another RECEIVE_AND_WAIT. 


Appendix B. Examples Using Basic Conversation Verbs 


B-27 



This page intentionally left blank 


B-28 


SNA Transaction Programmer's Reference Manual for LU Type 6.2 



APPENDIX C. SYMBOL STRING CONVENTIONS 


This manual refers to the following symbol strings: 

Network ID 
LU Name 

Fully-Qualified LU Name 
Node Name 

Transaction Program Name 
SECURITY Subfields 
PIP Subfields 
Nap Name 

This appendix defines the type and length of these symbol strings. 
The meanings of these symbol strings are defined in the chapters 
describing the individual verbs that refer to these symbol strings. 
The type and length of each symbol string is defined in terms of the 
send and receive support of all LU 6.2 products that implement the 
symbol string. 


SYMBOL STRING TYPE 


The symbol-string type identifies the set of characters from which the 
symbol string can be composed* and therefore the characters a trans¬ 
action program can use to specify the symbol string. The following 
symbol-string types are defined: 

• Type A (Assembler oriented): a character string consisting of one 
or more EBCDIC uppercase letters A through Z; numerics 0 through 
9; and special characters $* #* and 2>* the first character of 
which is an uppercase letter or a special character. 

• Type AE (A extended): a character string consisting of one or 
more EBCDIC lowercase letters a through z ; uppercase letters A 
through Z; numerics 0 through 9; special characters $* #* <&* and 
the period (.); with no restriction on the first character. 

• Type GR (EBCDIC graphics): a character string consisting of one 
or more EBCDIC characters in the range hex 41 through hex FE with 
no restriction on the first character. 

• Type DB (double byte): a byte string consisting of an even number 
of four or more bytes beginning with a byte of hex OE* followed by 
bytes in the range hex 41 through hex FE* and ending with a byte 
of hex OF. 

• Type G (general): a byte string consisting of one or more bytes 
in the range hex 00 through hex FF* with no restriction on the 
f i rst byte. 

The set of type-A and type-AE characters* and the hex codes for these 
characters* are shown in Figure C-l on page C-2. 
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Hex 

Code 

Gra- 
phi c 

Description 

Set 

A 

AE 

4B 


Period 


X 

5B 

$ 

Dollar Sign 

X 

X 

7B 

ft 

Number Sign 

X 

X 

7C 

3 

At 

Sign 

X 

X 

81 

a 

a , 

Small 


X 

82 

b 

b. 

Small 


X 

83 

c 

c. 

Small 


X 

84 

d 

d. 

Small 


X 

85 

e 

e. 

Small 


X 

86 

f 

f. 

Small 


X 

87 

g 

9> 

Small 


X 

88 

h 

h. 

Small 


X 

89 

i 

i > 

Small 


X 

91 

3 

3 p 

Small 


X 

92 

k 

k, 

Small 


X 

93 

1 

1* 

Small 


X 

94 

m 

m. 

Sma 11 


X 

95 

n 

n. 

Small 


X 

96 

o 

o. 

Small 


X 

97 

P 

Pr 

Small 


X 

98 

q 

q > 

Small 


X 

99 

r 

r. 

Small 


X 

A2 

s 

s. 

Small 


X 

A3 

t 

t. 

Small 


X 

A4 

u 

u. 

Small 


X 

A5 

V 

V, 

Small 


X 

A6 

w 

w. 

Small 


X 

A7 

X 

X, 

Small 


X 

A8 

y 

yp 

Small 


X 

A9 

2 

Zf 

Small 


X 

Cl 

A 

A, 

Capital 

X 

X 

C2 

B 

B, 

Capital 

X 

X 

C3 

C 

C, 

Capital 

X 

X 


Hex 

Code 

Gra¬ 

phic 

Description 

Set 

A 

AE 

C4 

D 

D, Capital 

X 

X 

C5 

E 

E, Capital 

X 

X 

C6 

F 

F, Capital 

X 

X 

C7 

G 

G, Capital 

X 

X 

€8 

H 

H, Capital 

X 

X 

C9 


I, Capital 

X 

X 

D1 


J, Capital 

X 

X 

D2 


K, Capital 

X 

X 

D3 


L, Capital 

X 

X 

D4 

M 

M, Capital 

X 

X 

D5 

N 

N, Capital 

X 

X 

D6 

0 

0, Capital 

X 

X 

D7 


P, Capital 

X 

X 

D8 


Q, Capital 

X 

X 

D9 


R, Capital 

X 

X 

E2 


S, Capital 

X 

X 

E3 


T, Capital 

X 

X 

E4 


U, Capital 

X 

X 

E5 


V, Capital 

X 

X 

E6 


W, Capital 

X 

X 

E7 

X 

X, Capital 

X 

X 

E8 


Y, Capital 

X 

X 

E9 


Z, Capital 

X 

X 

FO 


Zero 

X 

X 

FI 


One 

X 

X 

F2 

2 

Two 

X 

X 

F3 

3 

Three 

X 

X 

F4 


Four 

X 

X 

F5 


Five 

X 

X 

F6 


Six 

X 

X 

F7 

K9ii 

Seven 

X 

X 

F8 

■91 

Eight 

X 

X 

F9 

Kfl 

Nine 

X 

X 


Figure C-l. Character Sets A and AE 


Figure C-2 on page C-3 defines the product send support and receive 
support for each symbol string in terms of the symbol-string types* 
Depending on the symbol string, product send support or receive sup¬ 
port i s indicated either by a single type or multiple types. Where 
multiple types are indicated, the type selected is product-defined 
and send support may differ from receive support. 
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Symbol String 

Type 

Send Support 

Receive Support 

Network ID 

A 

A 

LU Name [1] 

- 

- 

Fully-Qualified LU Name [2] 

A.A 

A.A 

Mode Name 

A 

A 

Transaction Program Name 13] 

AE, GR, or DB 

A, AE, GR, or DB 

LU-LU Password [41 

- 


SECURITY Subfields 

AE, GR, or DB 

A, AE, GR, or DB 

PIP Subfields 

G 

G 

Map Name 

A, AE, or GR 

A, AE, or GR 


Notes: 

1. The LU name is a locally-known name; it is the name by which 
one LU knows another LU. A transaction program specifies 
this LU name in conjunction with the mode name when it 
allocates a session for a conversation. This LU name is not 
sent outside the LU. The symbol-string type is G. 

2. The fully-qualified LU name consists of two symbol strings of 

type A concatenated by a period The lefthand symbol 

string represents the network ID; the righthand symbol string 
represents the network LU name. The period is not part of 
the network ID or the network LU name. 

3. The first character of an SNA service transaction program 
name is a character ranging in value from hex 00 through hex 
0D and hex 10 through hex 3F (excluding hex 0E and hex OF). 
More details about SNA service transaction program names and 
a list of SNA service transaction programs is given in 
,f Appendix D. List of SNA Service Transaction Programs”. 

4. The LU-LU password is a locally-specified value and is not 
sent outside the LU. The symbol-string type is G. 


Figure 0-2. Symbol-String Types 
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SYMBOL STRING LENGTH 


The symbol-string length represents the number of characters a symbol 
string can contain. Three symbol-string lengths are defined: 

• Minimum specification length: the minimum number of characters 
that a transaction program is allowed to use to specify the symbol 
string. For some symbol strings* the minimum specification 
length is 2 ero. Zero-length strings are valid symbol strings and 
are subject to the same usage conditions as valid non-zero length 
strings. 1 

• Maximum send support: the maximum number of characters that all 
products can send for the symbol string. 

• Maximum receive support: the maximum number of characters that 
all products can receive for the symbol string. 

The maximum send or receive support for a symbol string 1 s length is 
defined either by a single value or Mi thin a range of values* depend¬ 
ing on the symbol string. 

The single value is the maximum number of characters in a symbol 
string that all products can send or receive. 

The range of values represents a lower and upper bound of the maximum 
number of characters in a symbol string that a product can send or 
receive. The specific maximum number of characters a product can send 
or receive for each of these symbol strings is product-defined within 
the range. 

Figure C-3 on page C-5 defines the product maximum send and receive 
support for each symbol string in terms of the symbol-string lengths. 
Where support is defined to be within a range of values* the range is 
given as ,f lower-value<—>upper-value*" which identifies the lower and 
upper bounds of the range. 

Note: The variable to which a type-A* type-AE* type-GR* or type-DB 
symbol string is assigned may be longer than the symbol string* in 
this case* the symbol string is left-justifi ed within the variable and 
the variable is filled out to the right with space (hex 40) charac¬ 
ters. Space characters, if present* are not part of the symbol 
string. If the symbol string is formed from the concatenation of two 
or more individual symbol strings* such as the fully-qualified LU 
name* the concatenated symbol string as a whole is left-justified 
within the variable and the variable is filled out to the right with 
space characters. Space characters* if present* are not part of the 
concatenated symbol string. 


A valid symbol string is one that meets the requirements of the 
symbol-string type defined for that symbol string. 
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Symbol String 

Length 

Minimum 

Specification 

Maximum 

Send Support 

Maximum 

Receive Support 

Network ID 

0 

8 

8 

LU Name C11 

0 

- 


Fully-Qualified LU Name 

1 

17 

17 

Node Name 

0 

8 

8 

Transaction Program Name 

i 

8<—>64 

8<—>64 

LU-LU Password t2] 

i 

- 


SECURITY Subfields 

0 

8<—>10 

0<->10 

PIP Subfields 133 

0 

64<—>* 143 

64<->x [53 

Map Name 

1 

8<->64 

7<—>64 


Notes: 

1* The LU name is a locally-known name; it is the name by which 
one LU knows another LU. A transaction program specifies 
this LU name in conjunction with the mode name when it 
allocates a session for a conversation. This LU name is not 
sent outside the LU. The maximum specification length of the 
LU name is product-defined. 

2. The LU-LU password is a locally-specified value and is not 
sent outside the LU. It is 64 bits (8 bytes) in length. At 
least 8 bits (1 byte) must be specified. If less than 64 
bits are specified, the local LU fills the password out to 
the right with binary 0's. 

3. Product support of PIP subfields is optional, and send 
support is independent of receive support. The maximum 
number of PIP subfields a product can send or receive is 
product-defined; it can be any number greater than or equal 
to 7. 

4. The maximum send support for PIP subfields is 
product-defined; it can be any length greater than or equal 
to 64. 

5. The maximum receive support for PIP subfields is 
product-defined; it can be any length greater than or equal 
to 64. 


Figure C-3. Symbol-String Lengths 
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APPENDIX D. LIST OF SNA SERVICE TRANSACTION PROGRAMS 


This appendix lists the classes of SNA service transaction programs* 
The SNA service transaction programs are categorized according to 
functional classes. A class is identified by the first one or two 
characters of the name. All SNA service transaction programs belong¬ 
ing to a given class have the same class identifier* 

The SNA service transaction program classes are: 


Class 


Identifier (in hex) 


Scheduler 02 

Queue 03 

DL/1 05 

Change Number of Sessions 06F1 

Resynchronization 06F2 

Distributed Data Management 07F0 

Document Interchange Architecture 20F0 
SNA Distribution Services 21F0 

Product Oriented 30F0 


SNA SERVICE TRANSACTION PROGRAM NAMES 

SNA service transaction programs are distinguished by their names* in 
particular the first (leftmost) character. The name of an SNA service 
transaction program can be one to four characters in length; typical¬ 
ly* however* they are four characters in length. The first character 
of the name can range in value from hex 00 through hex 0D and hex 10 
through hex 3F (excluding hex 0E and hex OF). The remaining charac¬ 
ters of the name are type-A* without any restriction on the first 
type-A character. By contrast* names of programs other than SNA serv¬ 
ice transaction programs are type-A* type-AE* type-GR* or type-DB 
symbol strings. 

Using the first character of the name* a product may restrict the 
right of access of its programs to SNA service transaction programs. 
For example* a product may allow only its "privileged” programs to 
allocate conversations to SNA service transaction programs* and pei— 
mit its "nonprivileged” programs to allocate conversations only to 
transaction programs other than SNA service transaction programs. 

Listed below are the individual SNA service transaction programs* 
grouped by class. 


SCHEDULER 

Name ( i n hex) Descr i pti on 

02 LU 6.1 scheduler transaction program. 

See the supporting IBM product's publications for more details. 

QUEUE 

Name (i n hex) Descri pti on 

03 LU 6.1 queue transaction program. 

See the supporting IBM product's publications for more details* 
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DL/1 


Name ( i n hex) Descri pt i on 

05 LU 6.1 DL/1 transaction program. 

See the supporting IBM product’s publications for more details. 


CHANGE NUMBER OF SESSIONS 

Name ( in hex) Description 

06F1 CNOS service transaction program 

See SNA Format and Protocol Reference Manual: Architecture Logic for 
LU Type 6.2 for more details. 


RESYNCHRONIZATION 

Name ( i n hex) Descri pt i on 

06F2 Sync point resynchronization transaction program. 

See SNA Format and Protocol Reference Manual: Architecture Logic for 
LU Type 6.2 and the supporting IBM product’s publications for more 
detaiIs. 

DISTRIBUTED DATA MANAGEMENT 

Name ( i n hex) Descri pti on 

07F0F0F1 Distributed data management synchronous conversation 

transaction program. 

See the supporting IBM product's publications for more details. 


DOCUMENT INTERCHANGE ARCHITECTURE 

Name (in hex) Description 

20F0F0F0 DIA process transaction program. 

20F0F0F1 DIA file server transaction program. 

See Document Interchange Architecture: Technical Reference for more 
detaiIs. 


SNA DISTRIBUTION SERVICES 


Name ( i n hex) Description 


21F0F0F1 

21F0F0F2 

21F0F0F3 

21F0F0F6 


SNADS DS_SEND transaction program. 

SNADS DS_RECEIVE transaction program. 

SNADS DS_ROUTER_DIRECTOR transaction program. 
SNADS general server transaction program. 


See SNA Format and Protocol Reference Manual; Distribution Services 
for more details. 


PRODUCT ORIENTED 


The following SNA service transaction programs are provided by spe¬ 
cific products. 


Name (in hex) Description 

30F0F0F0 Printer CPDS transaction program for IBM 3820. 

30F0F0F1 Printer level 2 transaction program for IBM 3820. 
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30F0F0F3 

30F0F0F4 

30F0F0F5 

30F0F0F6 

30F0F0F7 

See the IBM 


Object distribution transaction program for IBM Sys¬ 
tem/38 * 

NETDATA server transaction program for IBM System/38. 
IBM 5250 device passthrough transaction program for 
IBM System/36 and IBM System/38. 

Virtual disk transaction program for IBM System/36 and 
IBM System/38. 

Virtual printer transaction program for IBM System/36 
and IBM System/38. 

product's publications for more details. 
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APPENDIX E. CONVERSATION STATE MATRICES 


This appendix shows the conversation state transitions that can occur 
when a program issues a basic or type-independent conversation verb. 
A state transition can occur as a result of a verb the local program 
issues* a verb the remote program issued* or a network error* the lat¬ 
ter two are indicated when a return code of other than OK is returned 
to the local program. 

The conversation state transitions are represented by means of a 
matrix* see Figure E-l* Figure E-l* and Figure E-3. The columns of 
the matrix show the individual states* and the rows show the individ¬ 
ual verbs. A verb is shown more than once when a parameter of the verb 
or the return code determines the state transitions that can occur. 

Following the state-transition matrix is a matrix showing the 
state-check ABEND conditions that can occur; see Figure E-4. A state 
check occurs when the program attempts to issue a verb for a conversa¬ 
tion that is in a state in which the verb is not allowed. 

The conversation states are: 

Reset — the state in which the program can allocate the conversa¬ 
tion. 

Send — the state in which the program can send data* request con¬ 
firmation* or request sync point. 

Defer Receive and Defer Deallocate — the states in which the pro¬ 
gram can request sync point or confirmation* or simply flush the 
LU*s send buffer* when the synchronization level is SYNCPT. 

Receive — the state in which the program can receive information 
from the remote program. 

Confirm* Confirm Send* and Confirm Deallocate — the states in 
which the program can reply to a confirmation request. 

Sync-point* Sync-point Send, and Sync-point Deallocate — the 
states in which the program can respond to a sync point request. 

Deallocate — the state in which the program can deallocate the 
conversation locally. 

Abbreviations are used for the parameters* return codes* and 
what-received indications. The abbreviations and symbols used in the 
state-transition matrix are defined at the bottom of Figure E-3. 
Abbreviations and symbols used in the state-check matrix are defined 
at the bottom of Figure E-4. 
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Conversation States 


Defer Defer 
Receive Deallo¬ 
cate 


Receive Confirm 


Initiating Conversation 

ALLOCATECok] 

ALLOCATECael 

AlLOCATEtpe] 

ALLOCATECunl 


BACKOUT 
CONFIRMCokl 
CONFIRMCael 
CONFIRM!bol 
CONFIRMtdal 


CONFIRMCep] 
CONFIRMlrf] 
CONFIRMED 
DEALLOCATE!F)!okI 
DEALLOCATE!C)!ok! 


DEALLOCATE!S)!ok] 
DEALLOCATE!A)!ok] 
DEAL LOCATE!L)!ok] 
DEALLOCATE!C)!ae] 
DEALLOCATE!C)Ida] 


DEALLOCATE!C)[ep] 
DEALLOCATE!C)[rf] 
FLUSH 

GET_ATTRIBUTES 

GETTYPE 


POST.ON 

PREPARE' 

PREPARE. 

PREPARE. 

PREPARE 


PREPARE 

PREPARE 

PREPARE 

RECEIVE' 

RECEIVE 


RECEIVE 

RECEIVE 

RECEIVE" 

RECEIVE 

RECEIVE 


RECEIVE 

RECEIVE 

RECEIVE 

RECEIVE 

RECEIVE 


RECEIVE 

RECEIVE 

RECEIVE 

RECEIVE 


RECEIPT 

_TO_RECEIVE! FHok] 
_TO_RECEIVE!C)[ok] 
_TO_RECEIVE!S)[ok] 
TO_RECEIVE!C)[ae] 


.TO_RECEIVE!C)[daJ 
.TO_RECEIVE!C)[ep] 
,TO_RECEIVE!C)[rf] 
AND_WAIT[ok][daJ 
.AND_WAIT[ok][seJ 


AND_WAIT[okHco] 
AND_WAIT[ok]tcsl 
AND_WAIT[ok][cd] 
AND_WAIT[ok][sy] 
AND_WAIT[okHss] 


AND_WAIT!ok]tsdJ 
>ND_WAIT!ae] 
AND_WAIT!bo] 
AND_WAIT[da] 
_AND_WAIT[dn] 


.AND_WAIT!en] 
,AND_WAIT[ep] 
AND_WAIT[et] 
.AND_MAIT!rf ] 



Figure E-l. Conversation State Transition Matrix [Part 1 of 3) 
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Conversation States (continued) 

Verb 

Confirm 

Confirm 

Sync- 


Sync- 

Deallo- 


Send 

Deallo- 

point 


point 

cate 



cate 


S£9 

Deallo¬ 

cate 



7 

8 

9 

1 

ii 

12 


/ 

/ 

/ 

/ 

/ 

/ 

Initiating Conversation 

/ 

/ 

/ 

/ 

/ 

/ 

ALLOCATECokl 

/ 

/ 

/ 

/ 

/ 

/ 

ALLOCATEtae] 

/ 

/ 

/ 

/ 

/ 

/ 

ALLOCATECpe] 

/ 

/ 

/ 

/ 

/ 

/ 

ALLOCATECun] 

X 

X 

X 

X 

X 

/ 

BACKOUT 

/ 

/ 

/ 

/ 

/ 

/ 

CONFIRMEokl 

/ 

/ 

/ 

/ 

/ 

/ 

CONFIRMCaeJ 

/ 

/ 

/ 

/ 

/ 

/ 

CONFIRMEbol 

/ 

/ 

/ 

/ 

/ 

/ 

CONFIRMEdal 

/ 

/ 

/ 

/ 

/ 

/ 

CONFIRMEep] 

/ 

/ 

/ 

/ 

/ 

/ 

CONFIRMErf] 

2 

12 

/ 

/ 

/ 

/ 

CONFIRMED 

/ 

/ 

/ 

/ 

/ 

/ 

DEALLOCATE(F)Eok] 

/ 

/ 

/ 

/ 

/ 

/ 

DEALLOCATE(C)Eokl 

/ 

/ 

/ 

/ 

/ 

/ 

DEALLOCATE(S)Eokl 

i 

1 

i 

1 

i 

/ 

DEALLOCATECA)Eokl 

/ 

/ 

/ 

/ 

/ 

1 

DEALLOCATEE L)Eokl 

/ 

/ 

/ 

/ 

/ 

/ 

DEALLOCATE(C)Eael 

/ 

/ 

/ 

/ 

/ 

/ 

DEALLOCATE(C)tdal 

/ 

/ 

/ 

/ 

/ 

/ 

DEALLOCATE(C)Eep] 

/ 

/ 

/ 

/ 

/ 

/ 

DEALLOCATECOErf] 

/ 

/ 

/ 

/ 

/ 

/ 

FLUSH 

- 


- 

- 

- 

- 

GET ATTRIBUTES 

— 

- 

— 

- 

- 

- 

GET_TYPE 

/ 

/ 

/ 

/ 

/ 

/ 

POST ON RECEIPT 

/ 

/ 

/ 

/ 

/ 

/ 

PREPARE TO RECEIVE(F)Eok] 

/ 

/ 

/ 

/ 

/ 

/ 

PREPARE TO RECEIVEtOEokl 

/ 

/ 

/ 

/ 

/ 

/ 

PREPARE TO RECEIVE(S)Eokl 

/ 

/ 

/ 

/ 

/ 

/ 

PREPARE~TO_RECEIVE(C)Eae] 

/ 

/ 

/ 

/ 

/ 

/ 

PREPARE TO_RECEIVE(C)Eda] 

/ 

/ 

/ 

/ 

/ 

/ 

PREPARE TO RECEIVEECHep] 

/ 

/ 

/ 

/ 

/ 

/ 

PREPARE TO RECEIVECCKrfl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEokHda) 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE_AND_WAITEokHseJ 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND_WAITtok]EcoJ 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEoklEcsJ 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEoklEcd) 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEoklEsyl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE_AND_MAITEoklEssl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEoklEsdl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE_AND_MAITEael 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEbol 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEdal 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE_AND_MAITEdnl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND_MAITEenl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND_MAITEepl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND MAITEetl 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE AND_MAITErf1 
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Verb 


Conversation States 


RECEIVE_IMMEDIATElok](da) 
RECEIVE_IMMEDIATEtok3{seJ 
RECEIVE_IMMEDIATEtok3tcoJ 
RECEIVE_IMMEDIATElok3tcsl 
RECEIVE_IMMEDIATEtok3ted) 

RECEIVE_IMMEDIATEtok3{sy} 
RECEIVE_IMMEDIATEtok3(ssJ 
RECEIVE_IMMEDIATECok3(sdJ 
RECEIVE_IMMEDIATECae3 
RECEIVE_IMMEDIATECbo3 

RECEIVE_IMMEDIATECda3 
RECEIVE IMMEDIATEldnl 
RECEIVEllMMEDIATEIen] 
RECEIVE_IMMEDIATEIep3 
RECEIVE_IMMEDIATEtet3 

RECEIVE_IMMEDIATECrf3 

RECEIVE_IMMEDIATEtun3 

REQUEST_TO_SEND 

SEND_DATAtok3 

SEND_DATA[ae3 

SEND_DATAtbo3 
SEND_DATA[da3 
SEND_DATAtep3 
SEND_DATAtrf3 
SEHD_ERR0Rtok3 

SEHD_ERR0Rtae3 

SEND_ERR0Rtbo3 

SEND_ERR0Rtda3 

SEND_ERR0Rtdn3 

SEND_ERR0RIep3 

SEND ERRORtrf3 
SYNCPTtok3 
SYNCPTtbo3 
SYNCPTthm3 
TEST(P)Cok3 
TEST(P)[ae3 

TEST(P)Lbo3 
TEST(P)Cda3 
TEST(P)Cdn3 
TEST(P)ten3 
TEST(P)tep3 
TEST(P)Cet3 

TEST(P)tpn3 
TESTCP)t rf3 
TEST(P)tun3 
TEST(Q)tok3 
TEST(Q)tun3 



Figure E-2. Conversation State Transition Matrix (Part 2 of 3) 
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Conversation States (continued) 


Verb 


Confirm 

Confirm 

Sync- 

mm 

Sync- 

Deallo- 


Send 

Deallo- 

point 

nsfm 

point 

cate 



cate 


Bl 

Deallo- 






HHH 

cate 



7 

8 

9 

KfX 

11 

12 


/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEtokHda} 

/ 

/ 

/ 

/ 

/ ! 

/ 

RECEIVE IMMEDIATElokHse) 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMNEDIATECokHco) 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEIok](cs) 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE_IMMEDIATEtok3led} 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEEoklIsy) 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEtok](ssJ 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEtok!tsdJ 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATECae] 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE_IMMEDIATEtbo] 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATECda] 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEtdn] 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEten] 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEtep] 

/ 

/ 

' 

/ 

/ 

/ 

RECEIVE_IMMEDIATEtet3 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEtrf3 

/ 

/ 

/ 

/ 

/ 

/ 

RECEIVE IMMEDIATEtun] 

/ 

/ 

- 

/ 

/ 

/ 

REQUEST TO SEND 

/ 

/ 

/ 

/ 

/ 

/ 

SEND DATAtok] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND_DATAtae3 

/ 

/ 

/ 

/ 

/ 

/ 

SEND DATAtbo] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND DATAtda] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND DATAtep] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND DATAtrf3 

2 

2 

2 

2 

2 

/ 

SEND_ERR0RCok3 

/ 

/ 

/ 

/ 

/ 

/ 

SEND ERRORtae] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND ERRORtbo] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND ERRORtda] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND ERRORtdn] 

/ 

/ 

/ 

/ 

/ 

/ 

SEND_ERR0Rtep3 

12 

12 

12 

12 

12 

/ 

SEND ERROR!rf3 

/ 

/ 

5 

2 

12 

/ 

SYNCPTtok] 

/ 

/ 

x 

x 

X 

/ 

SYNCPTtbo] 

/ 

/ 

5 

2 

12 

/ 

SYNCPTthm] 

/ 

/ 

/ 

/ 

/ 

/ 

TEST(P)tok] 

/ 

/ 

/ 

/ 

/ 

/ 

TEST(P)tae3 

/ 

/ 

/ 

/ 

/ 

/ 

TEST(P)tbo3 

/ 

/ 

/ 

/ 

/ 

/ 

TEST<P)tda3 

/ 

/ 

/ 

/ 

/ 

/ 

TEST(P)tdn] 

/ 

/ 

/ 

/ 

/ 

/ 

TEST(P) ter*] 

/ 

/ 

/ 

/ 

/ 

/ 

TEST(P)Cep3 

/ 

/ 


/ 

/ 

/ 

TEST(P)Cet3 

/ 

/ 

/ \ 

/ 

/ 

/ 

TESTCP)Cpn3 

/ 

/ 

/ ! 

/ 

/ 

/ 

TEST CP)trf3 

/ 

/ 1 

/ 

/ 

/ 

/ 

TESTCP)tun3 

/ 

/ 

/ 

/ 

/ 

/ 

TESTCQ)tok3 

/ 

/ 

/ 

/ 

/ 

/ 

TEST(Q)tun] 
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Conversation States 


Reset I Send 


Defer 
Receive 


Defer 

Deallo¬ 

cate 


Receive Confirm 


UAITtok] 
WAIT faeJ 
WAITIbo] 
WAITCda] 
WAITtdnl 
WAITCen] 


WAITtep] 
WAITtetl 
WAITIpnl 
WAITtrf1 



Parameter Abbreviations (...) 

Return 

i-Code Abbreviations [...] 

A 

TYPECABEND PROG), TYPECABEND SVC), 

ae 

ALLOCATION ERROR 


or TYPE(ABEND TIMER) 

bo 

BACKED OUT 

c 

TYPE(CONFIRM ), or TYPE(SYNC LEVEL) 

da 

DEALLOCATE ABEND^PROG, 


with synchronization level CONFIRM 


DEALLOCATE ABEND_SVC» or 

F 

TYPE< FLUSH) 


DEALLOCATE ABEND TIMER 

L 

TYPE(LOCAL) 

dn 

DEALLOCATE NORMAL 

P 

TEST(POSTED) 

en 

PROG ERROR NO TRUNC or 

Q 

TEST(REQUEST TO SEND RECEIVED) 


SVC ERROR NO TRUNC 

S 

TYPE(SYNC_LEVEL) with 

ep 

PROG ERROR PURGING or 


synchronization level SYNCPT 


SVC ERROR PURGING 



et 

PROG ERROR TRUNC or 




SVC ERROR TRUNC 



nm 

HEURISTIC MIXED 



ok 

OK 



pe 

PARAMETER ERROR 



pn 

POSTING NOT_ACTIVE 



rf 

RESOURCE FAILURE NO RETRY or 




RESOURCE FAILURE_RETRY 



un 

UNSUCCESSFUL 


Figure E-3. Conversation State Transition Matrix (Part 3 of 3) 
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Conversation States (continued) 


Verb 


Confirra 

Confirm 

Sync- 

WBBSM 

Sync- 

Deallo- 


Send 

Deallo- 

point 


point 

cate 



cate 



Deallo- 






■■■ 

cate 



7 

8 

9 

■HHi 

11 

12 


/ 

/ 

/ 

/ 

/ 

/ 

WAITCokl 

/ 

/ 

/ 

/ 

/ 

/ 

WAITtae] 

/ 

/ 

/ 

/ 

/ 

/ 

UlAITCbo] 

/ 

/ 

/ 

/ 

/ 

/ 

WAITtda] 

/ 

/ 

/ 

/ 

/ 

/ 

WAITCdn] 

/ 

/ 

/ 

/ 

/ 

/ 

UAITCen] ! 

/ 

/ 

/ 

/ 

/ 

/ 

UAITCep] 

/ 

/ 

/ 

/ 

/ 

/ 

WAITCet] 

/ 

/ 

/ 

/ 

/ 

/ 

WAITCpnl 

/ 

/ 

/ 

/ 

/ 

/ 

WAITtrf3 


What- 

■Received Abbreviations (...) 

Matrix Svmbols 

co 

CONFIRM 

/ 

Verb cannot be issued in this 

cd 

CONFIRM DEALLOCATE 


state 

cs 

CONFIRM SEND 

- 

Remain in current state 

da 

DATA, DATA COMPLETE, 

number 

Number of next state 


DATA INCOMPLETE, or LL TRUNCATED 


State at completion of most 

sd 

TAKE SYNCPT DEALLOCATE 


recent synchronization point 


se SEND 

ss TAKE SYNCPT_SEND 
sy TAKElSYNCPT 


Appendix E. Conversation State Matrices 


E- 














Conversation States 


Defer Defer 
Receive Deallo¬ 
cate 


Receive Confirm 



Initiating Conversation 

ALLOCATE 

BACKOUT 

CONFIRM 

CONFIRMED 


DEALLOCATE(F) 

DEALLOCATECC) 

DEALLOCATE(S) 

DEALLOCATE(A) 

DEALLOCATE(L) 


FLUSH 

GET_ATTRIBUTES 
GET TYPE 
POST_ON_RECEIPT 
PREPARE_TO RECEIVE(F) 


PREPARE TO RECEIVE(C) 
PREPARElTOlRECEIVE(S) 
RECEIVE_AND_WAIT 
RECEIVE IMMEDIATE 
REQUEST T0_SEND 


SEND_DATA 

SEND_ERROR 

SYNCPT 

TEST(P) 

TEST(Q) 


Parameter Abbreviations (...) 

A TYPE(ABEND_PROG ), TYPE(ABEND_SVC), or TYPECABEND_TIMER) 

C TYPE(CONFIRM), or TYPE(SYNC_LEVEL) with synchronization level CONFIRM 
F TYPE(FLUSH) 

L TYPE(LOCAL) 

P TEST(POSTED) 

Q TEST(REQUEST_TO_SEND_RECEIVED) 

S TYPE(SYNC_LEVEL) with synchronization level SYNCPT 


Figure E-4. Conversation State Check Matrix 
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Conversation States (continued) 


Verb 


Conf irm 

Confirm 

Sync- 

Sy 

Send 

Deallo- 

point 

PO 


cate 


Se 

7 

8 

9 




Sync- 

Deallo- 

point 

cate 

Deallo¬ 


cate 


11 

12 



Initiating Conversation 

ALLOCATE 

BACKOUT 

CONFIRM 

CONFIRMED 


DEALLOCATE(F) 
DEALLOCATE(C) 
DEALLOCATECS) 
DEALLOCATE!A) 
DEALLOCATE!L) 


FLUSH 

GET_ATTRIBUTES 
GETJTYPE 
POST_ON_RECEIPT 
PREPARE_TO_RECEIVE(F) 


PREPARE TO RECEIVE(C) 
PREPARElTO_RECEIVE(S) 
RECEIVE AND WAIT 

receiveIimmediate 

REQUEST_TO_SEND 


SEND_DATA 

SEND_ERROR 

SYNCPT 

TEST(P) 

TEST(Q) 


Matrix Symbols 

> State check ABEND condition occurs in this state 

X State check ABEND condition occurs in this state if the program is in the 
process of sending a logical record and the record is incomplete 
/ State check ABEND condition cannot occur in this state 


Appendix E. Conversation State Matrices E- 
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INDEX 


E3 


ABEND conditions 

for basic conversation verbs 
.parameter check 3-8 
for LU 6.2 verbs 

product-dependent alterna¬ 
tives 3-8 
state check 3-8 
abnormal ending 

See ABEND conditions 
access security 

already verified indication 4-4* 

4-55 

for conversation 4-55 
for mapped conversation 4-4 
NONE 4-4 
PGM 4-5 
SAME 4-4 

access^ resource 5-35 
accumulating data 

in LU * s receive buffer 3-2 
in LU f s send buffer 3-2 
ACTIVATE_SESSION verb 5-19 
ACTIVATION_FAILURE_NQ_RETRY return code 
for control operator verbs 5-51 
ACTIVATION_FAILURE_RETRY return code 
for control operator verbs 5-51 
Advanced Program-to-Program Communi¬ 
cation (APPC) 1-3 
ALLOCATE verb 4-53 

used 6y LU services component 4-56 
used by transaction program 4-56 
allocation 

of a conversation 4-53 
of a mapped conversation 4-3 
of an LU-LU session 4-3, 4-53 
ALLQCATION_ERROR return code 

for control operator verbs 5-51 
for conversation verbs 4-99 
ALLOCATI0N_ERR0R subcodes 

for control operator verbs 

ALLOCATION_FAILURE_NO_RETRY 5-51 
ALLGCATION_FAILURE_RETRY 5-51 
T RAN S_P GM_N 0 T_AV AIL_R ETRY 5-51 
for conversation verbs 

ALLOCATION_FAILURE_NO_RETRY 4-99 
ALLOCATION_FAILURE — RETRY 4-99 
CONVERSATION_TYPE_MISMATCH 4-100 
PIP_N0T_ALL0WED 4-100 
PIP_NOT_SPECIFIED_CORRECTLY 4-100 
SECURITY_NOT_VALID 4-100 
SYNC_LEVEL_NOT_SUPPORTED_BY_LU 4-100 


allocation requests* draining 5-13 
already verified 5-27* 5-25 
already verified indication 4-4* 4-55 
APPC 

See Advanced Program-to-Program Com¬ 
munication (APPC) 

application transaction program 4-2* 
4-44 

arguments* parameter 

See parameter* arguments 
author!zation 1 i st 

resource access 5-35 




BACKED_OUT 
backed out 
of 


4-101 


A-20 


3-9 


SYNC_LEVEL_NOT_SUPPORTED_BY_PGM 
TPN_NOT_RECOGNIZED 4-100 
TRANS_PGM_NOT_AVAIL_NO_RETRY 4-100 
TRANS_PGM_NOT_AVAIL_RETRY 4-100 
ALLQCATION_FAILURE_NO_RETRY 

See ALLOCATIQN_ERR0R subcodes 
ALLOCATIQN_FAILURE_RETRY 

See ALLOCATIQN_ERR0R subcodes 
allocation request 

carrying transaction program 
name 3-1 


return code 
state 

a conversation 4-97 
See also conversation state 
changes 

backout request 

sent by BACKOUT verb 4-45 
BACKOUT verb 4-45 
base and optional support 

basic conversation verbs A-9 
CNOS verbs A-14 

control operator return codes A-19 
conversation return codes A-12 
LU definition verbs A-16 
mapped conversation verbs A-5 
notes on implementation details 
session control verbs A-15 
type-independent conversation 
verbs A-8 

what-received indications A-13 
base and options sets 

applicability to LU 6.2 products 
base set 

of LU 6.2 verbs 3-8 
base set of verbs 3-8 
base support of verbs 

See base and optional support 
basic conversation 

used as a CNOS conversation 5-4 
basic conversation verbs 4-52* 3-5* 
4-52 

See also individual verbs 
correlation to conversation 
states 4-98 
examples of use B-l 
boundary* protocol 

See protocol boundary 
4-100bracketed parameters 3-10 
buffering by LU 

general description 3-2 
of allocation request 4-6, 4-56 
of data 4-36* 4-88 
of deallocation request 4-13* 4-64 
of error notification 4-38* 4-90 
of SEND indication 4-23* 4-76 


Index X-l 



m 


change number of sessions 
See CNOS 

CHANGERSESSIQN^LIMIT verb 5-5 
changing 

(LU,mode) session limit 5-5 
contention-winner polarities 5-5 
operating parameters for a mode 5-30 
operating parameters for a remote 
LU 5-26 

operating parameters for a trans¬ 
action program 5-34 
operating parameters for the local 
LU 5-23 

character!stics, protocol boundary 

See protocol boundary characteristics 
cleanup, type of deactivation 5-21 
CNOS 

conversation 5-4 
request and reply 5-4 
transaction 5-4 
verbs 5-4 

CN0S_SUPP0RT parameter 

of DEFINE_REMOTE_LU verb 5-27 
of DISPLAY_REMOTE_LU verb 5-42 
COMMAND_RACE_REJECT return code 

for control operator verbs 5-51 
communication, interprogram 

See interprogram communication 
complete data record 

received by MC_RECEIVEJVND_WAIT 
verb 4-25 

received by MC_RECEIVEJEMMEDIATE 
verb 4-30 

CONFIRM_DEALLOCATE indication 

received by MC_RECEIVE_AND_WAIT 
verb 4-26 

received by MC_RECEIVE_IMMEDIATE 
verb 4-30 

received by RECEIVE_AND_WAIT 
verb 4-79 

received by RECEIVE_IMMEDIATE 
verb 4-83 
CONFIRM indication 

received by MCJ*ECEIVE_ANDJ4AIT 
verb 4-26 

received by MC_RECEIVE_IMMEDIATE 
verb 4-30 

received by RECEIVE_AND_WAIT 
verb 4-79 

received by RECEIVE_IMMEDIATE 
verb 4-83 

CONFIRM_SEND indication 

received by MC_RECEIVE_AND_WAIT 
verb 4-26 

received by MC_RECElVE — IMMEDIATE 
verb 4-30 

received by RECEIVE_AND_WAIT 
verb 4-79 

received by RECEIVE_IMMEDIATE 
verb 4-83 
confirm state 

of a conversation 4-97 

See also conversation state 
changes 

CONFIRM synchronization level 4-4, 4-54 
CONFIRM verb 4-59 
confirmation reply 

sent by CONFIRMED verb 4-61 
sent by MC_CONFIRMED verb 4-10 
confirmation request 


received by MC_RECEIVE_ANDJ4AIT 
verb 4-26 

received by MC_RECEIVE_IMMEDIATE 
verb 4-30 

received by RECEIVE_AND_WAIT 
verb 4-79 

received by RECEIVE_IMMEDIATE 
verb 4-83 

sent by CONFIRM verb 4-59 
sent by MC_CONFIRM verb 4-8 
CONFIRMED verb 4-61 
C0NL0SER$_SESSI0N_C0UNT parameter 
of DISPLAYJ10DE verb 5-46 
connection, LU-to-LU 

See LU-to-LU connection 
connection, program-to-program 

See program-to-program connection 
contention winner and loser 
See LU-LU session 
contention-winner polarities 
changing 5-5 
initializing 5-8 
processing by target LU 5-16 
resetting 5-12 
control-operator 

transaction program 5-1 
control-operator verbs 5-1, 3-6 
See also individual verbs 
correlation to return codes 5-54 
return codes for 

See return codes for control oper¬ 
ator verbs 
subcategories 5-3 
conversation 

allocated on LU-LU session 2-1 
allocation of 4-53 
changing to receive state 
using PREPARE_TO_RECEIVE 
verb 4-73 

using RECEIVE_ANDJ4AIT verb 4-77 
changing to send state 

using SEND_ERROR verb 4-90 
deallocation of 4-62 
obtaining attributes of 4-68 
requesting change to send state 

using REQtJEST_TO_SEND verb 4-86 
send-receive relationship 3-2 
starting, resource ID of 3-1 
two-way alternate data transfer 3-2 
CONVERSATIQN_CQRRELATOR parameter 

of MC_GET_ATTRIBUTES verb 4-17, 4-69 
conversation-level security 5-29 
conversation-level security verifica¬ 
tion 5-23 

conversation resource 1-3 
conversation state changes 

backed-out state, entered by 

BACKED_OUT return code 4-101 
confirm state, entered by 

RECEIVE_AND_UAIT verb 4-79 
RECEIVERMMEDIATE verb 4-84 
deallocate state, entered by 

ALLOCATI0N_ERR0R return code 4-99 
CONFIRMED verb 4-61 
DEALLGCATE_ABEND_PROG return 
code 4-101 

DEALL0CATE_ABEND return 
code 4-101 

DEALLQCATE_ABEND_SVC return 
code 4-101 

DEALLOCATE_ABENDJTIMER return 
code 4-101 

DEALLOCATE.NORMAL return 
code 4-101 
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MC_CONFIRMED verb 4-10 
RESOURCE_FAILURE_NO_RETRY return 
code 4-103 

RESOURCE_FAILURE_RETRY return 
code 4-103 
SYNCPT verb 4-47 
defer state* entered by 
DEALLOCATE verb 4-63 
PREPARE_TO_RECEIVE verb 4-74 
receive state* entered by 
CONFIRM verb 4-59 
CONFIRMED verb 4-61 
connected remote program 4-57 
FLUSH verb 4-67 
PREPARE_TO_RECEIVE verb 4-74 
PROG_ERROR_PURGING return 
code 4-103 

RECEIVE_AND_WAIT verb 4-79 
SVC_ERROR_PURGING return 
code 4-103 
SYNCPT verb 4-47 
reset state* entered by 
CONFIRM verb 4-59 
DEALLOCATE verb 4-63 
FLUSH verb 4-67 
SYNCPT verb 4-47 
send state* entered by 
ALLOCATE verb 4-56 
CONFIRMED verb 4-61 
FMH_DATA_NOT_SUPPORTED return 
code 4-101 

MAP_EXECUTION_FAILURE return 
code 4-102 

MAP_NOT_FOUND return code 4-102 
MAPPING_NOT_SUPPORTED return 
code 4-102 

MC CONFIRMED verb 4-10 
RECEIVE_AND_WAIT verb 4-79 
RECEIVE IMMEDIATE verb 4-84 
SEND_ERROR verb 4-91 
SYNCPT verb 4-47 
state after last synchronization 
point* entered by 
BACKOUT verb 4-45 
state unchanged by 
CONFIRM verb 4-59 
FLUSH verb 4-67 
GET_ATTRIBUTES verb 4-69 
GET_TYPE verb 4-46 
MC_POST_ON_RECEIPT verb 4-18 
MC_TEST verb 4-41 
P0ST_0N_RECEIPT verb 4-70 
RECEIVE_AND_WAIT verb 4-79 
RECEIVE_IMMEDIATE verb 4-84 
REQUEST_TO_SEND verb 4-86 
SEND_DATA verb 4-88 
SEND_ERROR verb 4-91 
SYNCPT verb 4-47 
TEST verb 4-95 
WAIT verb 4-51 
sync-point state* entered by 
RECEIVE_AND__WAIT verb 4-79 
RECEIVE_IMMEDIATE verb 4-84 
conversation state matrices E-l 
conversation states 

See also conversation state changes 
backed out 4-97 
confirm 4-97 

correlation to basic conversation 
verbs 4-98 
deallocate 4-97 
defer 4-97 

local program's view of 4-97 
receive 4-97 


reset 4-97 
send 4-97 
sync point 4-97 
conversation type 3-3 

specified by TYPE parameter 4-54 
CONVERSATION_TYPE_MISMATCH 

See ALL0CATI0N_ERR0R subcodes 
CONVERSATION TYPE parameter 
of DEFINE~TP verb 5-35 
of DISPLAY_TP verb 5-47 
conversation verbs 4-1* 3-3 

correlation to return codes 4-105 
return codes for 

See return codes for conversation 
verbs 

subcategories 4-1 

C0NWINNER_AUT0 ACTIVATE_LIMIT parameter 
of DEFIHE_M0DE verb 5-32 
of DISPLAYJ10DE verb 5-46 
CONWINNERS_SESSION_COUNT parameter 
of DISPLAY_MODE verb 5-46 


m 


data 

See also OK subcodes 
mapping 4-35 
posting receipt of 4-70 
received by RECEIVE_AND_WAIT 
verb 4-77 

received by RECEIVE_IMMEDIATE 
verb 4-82 

sent by SEND_DATA verb 4-87 
Data Encryption Standard CDES) 5-28 
data field of a logical record 4-87 
DATA_MAPPING parameter 

of DEFINE.TP verb 5-37 
of DISPLAYJTP verb 5-48 
DATA parameter 

of MC RECEIVE_AND_WAIT verb 4-25 
of MC_RECEIVE_IMMEDIATE verb 4-30 
of MC SEND_DATA verb 4-35 
of RECEIVE_AND_WAIT verb 4-78 
of RECEIVE_IMMEDIATE verb 4-83 
of SEND_DATA verb 4-87 
data record 

posting receipt of 4-18 
received by MC_RECEIVE_AND_WAIT 
verb 4-24 

received by MC_RECEIVE_IMMEDIATE 
verb 4-29 

sent by MC__SEND_DATA verb 4-35 
DEACTIVATE_SE5SI0N verb 5-21 
DEALLOCATE_ABEND_PROG return code 4-101 
DEALLOCATEDBEND return code 4-101 
DEALLOCATE_ABEND_SVC return code 4-101 
DEALLOCATE_ABEND_TIMER return 
code 4-101 

DEALLOCATE_NQRMAL return code 4-101 
deallocate state 

of a conversation 4-97 

See also conversation state 
changes 

DEALLOCATE verb 4-62 
deallocation 

of a conversation 4-62 
of a mapped conversation 4-11 
defer state 

of a conversation 4-97 

See also conversation state 
changes 


Index 
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DEFINE_LOCAL_lU verb 5-23 
DEFINE MODE verb 5-30 
DEFINE_REMOTE_LU verb 5-26 
DEFINE_TP verb 5-34 
DELETE verb 5-49 
deleting 

operating parameters of local 
LU 5-49 

DISPLAY_10CAL_LU verb 5-40 
DISPLAYJ10DE verb 5-44 
DI5PLAY_REM0TE_LU verb 5-42 
DISPLAY.TP verb 5-47 
displaying 

operating parameters for a mode 5-44 
operating parameters for a remote 
LU 5-42 

operating parameters for a trans¬ 
action program 5~47 
operating parameters for the local 
LU 5-40 

DRAIN_LOCAL_LU parameter 

of DISPLAY MODE verb 5-46 
DRAIN_REMOTE_LU parameter 

of DISPLAYJ10DE verb 5-46 
DRAIN_SOURCE parameter 

of RESET_SESSION_LIMIT verb 5-13 
DRAIN_TARGET parameter 

of RESET_SESSION_LIMIT verb 5-13 


czi 


effective program-to-program con¬ 
nection 2-2 
END statement 3-2 
error notification 

indicated by return code 4-102 
sent by MC_$ENDJERROR verb 4-38 
sent by SEND_ERROR verb 4-90 
execution 

transaction program 3-1 
verb 3-2 


ED 


FILL parameter 

of P0ST_0N_RECEIPT verb 4-70 
of RECEIVE AND_WAIT verb 4-77 
of RECEIVE.IMMEDIATE verb 4-82 
FLUSH verb 4-67 
flushing LU's send buffer 
by ALLOCATE verb 4-56 
by BACKOUT verb 4-45 
by CONFIRM verb 4-59 
by DEALLOCATE verb 4-63 
by FLUSH verb 4-67 
by MC_ALLOCATE verb 4-6 
by MC_CONFIRM verb 4-8 
by MC_DEALLOCATE verb 4-12 
by MC FLUSH verb 4-15 
by MC_PREPARE_TO_RECEIVE verb 4-20 
by MC_RECEIVE AND_WAIT verb 4-24 
by MC_SEND_ERROR verb 4-38 
by PREPARE_TO_RECEIVE verb 4-73 
by RECEIVE AND_WAIT verb 4-77 
by SEND_ERROR verb 4-90 
by SYNCPT verb 4-47 


general description 3-2 
FM header data 

received by MC_RECEIVE_AND_WAIT 
verb 4-25 

received by MC_RECEIVE IMMEDIATE 
verb 4-30 

sent by MC_SEND_DATA verb 4-35 
FMH_DATA_NOT_SUPPORTED return 
code 4-101 
FMH_DATA parameter 

of DEFINE TP verb 5-37 
of DISPLAY_TP verb 5-48 
of MC_SEND_DATA verb 4-35 
FORCE parameter 

of RESET SESSION_LIMIT verb 5-14 
FULLY QUALIFIED LU NAME parameter 
of DEFINE_LOCAL_LU verb 5-23 
of DEFINEJ10DE verb 5-30 
of DEFINE_REMOTE_LU verb 5-26 
of DISPLAY_LOCAL_LU verb 5-40 
of DISPLAYJ10DE verb 5-45 
of DISPLAY_REMOTE LU verb 5-42 




generic protocol boundary 1-2 
GET_ATTRIBUTES verb 4-68 
GET_TYPE verb 4-46 




half-duplex data transfer 

See two-way alternate data transfer 
HEURISTIC_MIXED return code 4-101 
hex (hexadecimal) 4-87 




incomplete data record 

received by MC_RECEIVE_AND_WAIT 
verb 4-25 

received by MC_RECEIVE_IMMEDIATE 
verb 4-30 

INITIALIZERSESSI0N_LIMIT verb 5-8 
initializing 

(LU»mode) session limit 5-8 
contention-winner polarities 5-8 
operating parameters for a mode 5-30 
operating parameters for a remote 
LU 5-26 

operating parameters for a trans¬ 
action program 5-34 
operating parameters for the local 
LU 5-23 

INITIATE TYPE parameter 

of DEFINErREMOTErLU verb 5-27 
of DISPLAYrREMOTErLU verb 5-42 
instance of transaction program 3-1 
interconnection of programs 
initiating 2-2 
logical 2-2 

interprogram communication 2-1* 1-3 
issuing verbs 3-2 
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CD 


length (LL) field of a logical 
record 4-87 
LENGTH parameter 

of MC_P0ST_0N RECEIPT verb 4-18 
of MC_RECEIVE_ANDJ4AIT verb 4-24 
of MC_RECEIVE_IMMEDIATE verb 4-29 
of MC_SEND_DATA verb 4-35 
of P0ST_0N RECEIPT verb 4-70 
of RECEIVE_AND_WAIT verb 4-77 
of RECEIVEjmMEDIATE verb 4-82 
of SEND_DATA verb 4-87 
lengths of symbol strings C-l 
local LU 

defining operating parameters 
for 5-23 
definition 3-3 
deleting operating parameters 
of 5-49 

displaying operating parameters 
for 5-40 

L0CAL_LU NAME parameter 
of DELETE verb 5-49 
local program 

definition 3-3 
local resources 1-1 
local support 

of LU 6.2 verbs 3-8 
LOCALLY_KNOWN_LU_NAME parameter 
of DEFINE_REMOTE_LU verb 5-26 
of DISPLAY_REMOTE_LU verb 5-42 
LOCKS parameter 

of MC_PREPARE_TO_RECEIVE verb 4-20 
of PREPARE_TO_RECEIVE verb 4-73 
L0G_DATA parameter 

of DEALLOCATE verb 4-63 
of SEND_ERROR verb 4-90 
logical network 1-1 
logical records 

complete and incomplete 4-88 
data field of 4-87 
length (LL) field of 4-87 
posting receipt of 4-70 
received by RECEIVE_ANDJaIAIT 
verb 4-77 

received by RECEIVE_IMMEDIATE 
verb 4-82 

sent by SEND_DATA verb 4-87 
logical resources 1-1 
logical unit (LU) 1-1 
See also LU 

logical unit type 6.2 1-1 

LU 

local 3-3 

See also local LU 
remote 3-3 

See also remote LU 
source 5-4 

See also source LU 
target 5-4 

See also target LU 
LU definition verbs 5-22 
LU-LU password 

example for entering 5-28 
use 5-28 

LU^LU^PASSWORD parameter 


of DEFINE_REMOTE_LU verb 5-27 
LU-LU session 
activation 

by ACTIVATE_SESSION verb 5-19 
by CHANGE_SESSION_LIMIT verb 5-5 
by INITIALIZE_SESSION_LIMIT 
verb 5-8 

allocation of 4-3* 4-53 
contention loser 2-1 
contention winner 2-1 
conversation allocated on 2-1 
deactivation 

by CHANGE_SESSION_LIMIT verb 5-5 
by DEACTIVATE_SESSION verb 5-21 
by RESET_$ESSIGN_LIMIT verb 5-12 
logical connection 1-1 
LUs connected by 2-1 
serially reusable resource 1-3 
LU-LU sessions 5-1 
parallel 5-1 
single 5-1 

LU MODELSESSI0N_C0UNT parameter 
“of DISPLAYJ10DE verb 5-46 
LU_MODE_SESSIQN_LIMIT_CLQSED return code 
for control operator verbs 5-52 
LU_MODE_SESSION_LIMIT_EXCEEDED return 
code 

for control operator verbs 5-52 
LU_M0DE_SESSI0N_LIMIT_N0T_ZER0 return 
code 

for control operator verbs 5-52 
LU MQDE_SESSION_LIMIT parameter 

“of CHANGERSESSION LIMIT verb 5-5 
of DISPLAY_MODE verb 5-46 
of INITIALIZE_SESSION_LIMIT verb 5-8 
LU_MODE_SESSION_LIMIT_ZERO return code 
for control operator verbs 5-52 
LU_NAME parameter 

“of ACTIVATE_SESSION verb 5-19 
of ALLOCATE verb 4-53 
of CHANGE_SESSION_LIMIT verb 5-5 
of INITIALIZE_SESSION_LIMIT verb 5-8 
of MC_ALLOCATE verb 4-3 
of PROCESS_SESSION_LIMIT verb 5-16 
of RESET_SESSION_LIMIT verb 5-12 
LU services component program 4-52 
LU_SESSION_CQUNT parameter 

of DISPLAY_LOCAL_LU verb 5-40 
LU_SESSION_LIMIT_EXCEEDED return code 
for control operator verbs 5-52 
LU SESSION_LIMIT parameter 

“of DEFINEJ.OCAL_LU verb 5-23 
of DISPLAY_LOCAL_LU verb 5-40 
LU-to-LU connection 

parallel-session 5-1 
single-session 5-1 
LU 6.2 

protocol boundary 2-1 
type of logical unit 1-1 
LU>mode session limit 
changing 5-5 
initializing 5-8 
processing by target LU 5-16 
resetting 5-12 

specified by LUJ10DE_SESSI0N_LIMIT 
parameter 5-5 
LUW_IDENTIFIER parameter 

of GET_ATTRIBUTES verb 4-69 
of MC GET ATTRIBUTES verb 4-17 
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m 

MAP_EXECUTION_FAILURE return code 4-101 
MAP_NAME parameter 

of DEFINE_LOCAL_LU verb 5-24 
of MC_RECEIVE_AND_WAIT verb 4-26 
of MC_RECEIVE_IMMEDIATE verb 4-31 
of MC_SEND_DATA verb 4-35 
MAP_NAMES 

of DISPLAY_LOCAl__LU verb 5-40 
MAP_N0T_F0UND return code 4-102 
mapped conversation 
allocation of 4-3 
changing to receive state 

using MC_PREPARE_TO_RECEIVE 
verb 4-20 

using MC_RECEIVE_AND_WAIT 
verb 4-24 

changing to send state 

using MC_SEND_ERROR verb 4-38 
deallocation of 4-11 
obtaining attributes of 4-16 
requesting change to send state 
using MC_REQUESTJTO_SEND 
verb 4-34 

mapped conversation state changes 
confirm state, entered by 

MC_RECEIVE_AND_WAIT verb 4-26 
MC_RECEIVE_IMMEDIATE verb 4-31 
defer state, entered by 

MC_DEALLOCATE verb 4-12 
MC_PREPARE_TO_RECEIVE verb 4-21 
receive state, entered by 

connected remote program 4-7 
MC_COHFIRM verb 4-8 
MC_C0NF1RMED verb 4-10 
MC_FLUSH verb 4-15 
MC_PREPARE_TO_RECEIVE verb 4-22 
MC_RECEIVE_AND_WAIT verb 4-26 
reset state, entered by 
MC_CONFIRM verb 4-8 
MC_DEALLOCATE verb 4-12 
MC_FLUSH verb 4-15 
send state, entered by 
MC_ALLOCATE verb 4-6 
MC_RECEIVE_AND_WAIT verb 4-26 
MC_RECEIVE_IMMEDIATE verb 4-31 
MC_SEND_ERROR verb 4-39 
state unchanged by 

MC_CONFIRM verb 4-8 
MC_FLUSH verb 4-15 
MC_GET_ATTRIBUTES verb 4-17 
MC_RECEIVE_AND_WAIT verb 4-26 
MC_RECEIVE_IMMEDIATE verb 4-31 
MC_REQUEST_TO_SEND verb 4-34 
MC_SEND_DATA verb 4-36 
MC_SEHD_ERROR verb 4-39 
sync-point state, entered by 

MC_RECEIVE_AND_WAIT verb 4-26 
MC_RECEIVE_IMMEDIATE verb 4-31 
mapped conversation verbs 4-2, 3-3, 4-2 
See also individual verbs 
MAPPING_NOT_SUPPORTED return code 4-102 
mapping of data 4-35 
MC_ALLOCATE verb 4-3 
MC_CONFIRM verb 4-8 
MC_CONFIRMED verb 4-10 
MC_DEALLOCATE verb 4-11 
MC_FLUSH verb 4-15 
MC_GET_ATTRIBUTES verb 4-16 
MC_POST_ON_RECEIPT verb 4-18 
MC_PREPARE_TO_RECEIVE verb 4-20 


MC_RECEIVE_AND WAIT verb 4-24 
MC_RECEIVE_IMMEDIATE verb 4-29 
MC_REQUEST_TO_SEND verb 4-34 
attention mechanism 

See MC_REQUEST_TO_SEND verb 
MC_SEND_DATA verb 4-35 
MC_SEND_ERROR verb 4-38 
MIN_C0NL0SERS parameter 

of DISPLAYJ10DE verb 5-46 
MIN_CONWINNERS parameter 

of DISPLAY_MODE verb 5-46 
MIN_CONWINNERS_SOURCE parameter 

of CHANGE_SESSION_LIMIT verb 5-5 
of INITIALIZE_SESSION_LIMIT verb 5-8 
MIN_CONWINNERS_TARGET parameter 

of CHANGE_SESSION_LIMIT verb 5-6 
of INITIALIZE_SESSION_LIMIT verb 5-9 
mode 

defining operating parameters 
for 5-30 

displaying operating parameters 
for 5-44 

M0DE_NAME parameter 

of ACTIVATE.SESSION verb 5-19 
of ALLOCATE verb 4-53 
of CHANGE SESSION LIMIT verb 5-5 
of DEFINEJ10DE verb 5-30 
of DELETE verb 5-49 
of DISPLAY_MODE verb 5-45 
of GET_ATTRIBUTES verb 4-68 
of INITIALIZE_SESSION_lIMIT verb 5-8 
of MC_ALLOCATE verb 4-3 
of MC_GET_ATTRIBUTES verb 4-16 
of PROCESS_SESSION_LIMIT verb 5-16 
of RESET_SESSION_LIMIT verb 5-12 
MODE_NAMES parameter 

of DISPLAY_REMOTELU verb 5-43 


m 


name 

LU 4-3# 4-53 
mode 4-3# 4-53 

transaction program 3-1# 4-3# 4-54 
negotiation of CMOS parameters 5-52 
network 

logical 1-1 
physical 1-1 

network properties designated by mode 
name 4-3# 4-53 

NONE access security 4-4# 4-55 
NONE synchronization level 4-4# 4-54 
normal# type of deactivation 5-21 
NGT_DATA 

See OK subcodes 




OK return code 

for control operator verbs 5-52 
for conversation verbs 4-102 
OK subcodes 

for control operator verbs 
AS_NEG0TIATED 5-52 
AS_SPECIFIED 5-52 
FORCED 5-52 
for conversation verbs 
DATA 4-102 
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NOT_DATA 4-102 
OK subcodes 

See OK subcodes 

operating parameters for a mode 
defining 5-30 
displaying 5-44 

operating parameters for a remote LU 
defining 5-26 
displaying 5-42 

operating parameters for a transaction 
program 

defining 5-34 
displaying 5-47 

operating parameters for the local LU 
defining 5-23 
displaying 5-40 

operating parameters of local LU 
deleting 5-49 
option sets 

of LU 6.2 verbs 3-8 
optional sets of verbs 3-8 
optional support of verbs 

See base and optional support 
overview description of verbs 3-3 
OWN_FULLY_QUALIFIED_LU_NAME parameter 
of GET_ATTRIBUTES verb 4-68 
of MO GET ATTRIBUTES verb 4-16 



PARALLEL_$ESSION_SUPPORT parameter 
of DEFINE_REM0TE_LU verb 5-27 
of DI5PLAY_REM0TEJ.U verb 5-42 
parallel sessions 
definition 5-1 
parameter 
arguments 

ke"yword 3-10 
variable 3-10 
vertical list of 3-10 
name 3-10 
parameter check 

See ABEND conditions 
PARAMETER^ERROR return code 

for control operator verbs 5-52 
for conversation verbs 4-102 
parameters# verb 

See verb# parameters 
PARTNER_FULLY_QUALIFIED_LU_NAME parame¬ 
ter 

of GET_ATTRIBUTES verb 4-68 
of MC_GET_ATTRIBUTES verb 4-16 
PARTNER_LU_NAME parameter 

of GET_ATTRIBUTES verb 4-68 
of MC_GET_ATTRIBUTES verb 4-16 
PGM access security 4-5# 4-55 
physical network 1-1 
PIP 

See program initialization parameters 
(PIP) 

PIP N0T_ALL0WED 

See ALL0CATI0N_ERR0R subcodes 
PIP_NOT_SPECIFIED_CORRECTLY 

See ALL0CATI0N_ERR0R subcodes 
PIP parameter 

of ALLOCATE verb 4-55 
of DEFINE_7P verb 5-37 
of DISPLAY_TP verb 5-48 
of MC ALLOCATE verb 4-5 
P0ST_0N_RECEIPT verb 4-70 
POSTING_NQT_ACTIVE return code 4-102 


PREPARE TO RECEIVE verb 4-73 
PROCEDURE statement 3-1 
PROCESS_SESSIGN_LIMIT verb 5-16 
processing by target LU 

(LU#mode) session limit 5-16 
contention-winner polarities 5-16 
product-support subsetting 

applicabi1ity to LU 6.2 products 3-9 
definition 3-8 

PR0G_ERR0R_N0_TRUNC return code 4-102 
PROG ERROR_PURGING return code 4-103 
PROG_ERROR_TRUNC return code 4-103 
program 

interconnection 2-2 
local 3-3 

See also local program 
remote 3-3 

See also remote program 
transaction 

See transaction program 
program initialization parameters (PIP) 
on ALLOCATE verb 4-55 
on MC_ALLOCATE verb 4-5 
on PROCEDURE statement 3-1 
program-to-program connection 
effective 2-2 
through SNA network 2-1 
protected resource 

See also resources# protected 
allocating a conversation as 4-54 
allocating a mapped conversation 
as 4-4 

backout of 4-45 
sync point of 4-47 
protocol boundary 
definition 1-2 
generic 1-2 
LU 6.2 2-1 

states 2-2 
structure 2-2 
verbs 2-2 

protocol boundary characteristics 
attention mechanism 1-3 
commitment control 1-4 
conversation lifetime 1-3 
conversation overhead 1-3 
efficient allocation 1-3 
error notification 1-4 
levels of conversations 1-4 
mode of service 1-4 
simultaneous activation 1-3 
subset definition 1-4 
symmetry 1-4 
sync-point service 1-4 
two-way alternate data transfer 1-3 
purging of information 

by MC SEND_ERROR verb 4-39 
by SEHD_ERROR verb 4-92 
return codes indicating 4-103 



RECEIVE_AND_WAIT verb 4-77 
receive buffer of LU 

accumulating data in 3-2 
RECEIVE_IMMEDIATE verb 4-82 
RECEIVEJ1AX_RU_SIZE_L0WER_BGUND parame¬ 
ter 

of DEFINEJ10DE verb 5-31 
of DISPLAYJ10DE verb 5-45 


Index 


X-7 



RECEIVE_MAX_RU_SIZE_UPPER_BOUND parame¬ 
ter 

of DEFINE_MODE verb 5-31 
of DISPLAY_MODE verb 5-45 
RECEIVE_PACING WINDOW parameter 
of DEFINE MODE verb 5-31 
of DISPLAY_MODE verb 5-45 
receive state 

changing conversation to 
using PREPARE_TO_RECEIVE 
verb 4-73 

using RECEIVE_AND_WAIT verb 4-77 
changing mapped conversation to 
using MC_PREPARE_TO_RECEIVE 
verb 4-20 

using MC_RECEIVE_AND_WAIT 
verb 4-24 

of a conversation 4-97 

See also conversation state 
changes 

receive support of symbol strings C-3 
receiving information 

using MC_RECEIVE_AND_WAIT verb 4-24 
using MC_RECEIVE_IMMEDIATE verb 4-29 
using RECEIVE_AND_WAIT verb 4-77 
using RECEIVE_IMMEDIATE verb 4-82 
remote LU 

defining operating parameters 
for 5-26 
definition 3-3 

displaying operating parameters 
for 5-42 

specified by LU_NAME parameter 4-3» 
4-53 

REMOTE_LU_NAME parameter 
of DELETE verb 5-49 
REMOTE_LU_NAMES 

of DISPLAY_LOCAL_LU verb 5-40 
remote program 

definition 3-3 

specified by TPN parameter 4-3, 4-54 
remote resources 1-1 
remote support 

of LU 6.2 verbs 3-9 
REQUEST_EXCEEDS_MAX_ALLOWED return code 
for control operator verbs 5-53 
REQUEST_TO_SEND_RECEIVED parameter 
of CONFIRM verb 4-59 
of MC_CONFIRM verb 4-8 
of MC_RECEIVE_AND_WAIT verb 4-25 
of MC_RECEIVE_IMMEDIATE verb 4-29 
of MC_SEND_DATA verb 4-36 
of MC_SEND_ERROR verb 4-38 
of RECEIVE_AND_WAIT verb 4-78 
of RECEIVE_IMMEDIATE verb 4-83 
of SENDJ3ATA verb 4-87 
of SEND_ERROR verb 4-91 
of SYNCPT verb 4-47 
REQUEST_TO_SEND verb 4-86 
RESET_SESSION_LIMIT verb 5-12 
reset state 

of a conversation 4-97 

See also conversation state 
changes 
resetting 

<LU,mode) session limit 5-12 
contention-winner polarities 5-12 
resource 

obtaining type of 4-46 
resource access 

RESOURCE_FAILURE_NO_RETRY return code 
for control operator verbs 5-53 
for conversation verbs 4-103 


RESOURCE_FAILURE_RETRY return 
code 4-103 
resource ID 

assigned to conversation 4-53 
assigned to mapped conversation 4-3 
of starting conversation 3-1 
unassigned from conversation 4-62 
unassigned from mapped conversa¬ 
tion 4-11 

RESOURCE_LIST parameter 
of WAIT verb 4-50 
RESOURCE parameter 

of ALLOCATE verb 4-55 
of CONFIRM verb 4-59 
of CONFIRMED verb 4-61 
of DEALLOCATE verb 4-62 
of FLUSH verb 4-67 
of GET_ATTRIBUTES verb 4-68 
of GET_TYPE verb 4-46 
of MC_ALLOCATE verb 4-5 
of MC_C0NFIRM verb 4-8 
of MC_CONFIRMED verb 4-10 
of MC_DEALLOCATE verb 4-11 
of MC_FLUSH verb 4-15 
of MC_GET_ATTRIBUTES verb 4-16 
of MC_POST_ON_RECEIPT verb 4-18 
of MC_PREPARE_TO_RECEIVE verb 4-20 
of MC_RECEIVE_AND_WAIT verb 4-24 
of MC_RECEIVE_IMMEDIATE verb 4-29 
of MC_REQUEST_TO_SEND verb 4-34 
of MC SEND_DATA verb 4-35 
of MCjSEND_ERROR verb 4-38 
of MC_TEST verb 4-41 
of P0ST_0N_RECEIPT verb 4-70 
of PREPARE_TO_RECEIVE verb 4-73 
of PROCESS_SESSION_LIMIT verb 5-16 
of RECEIVE_AND_WAIT verb 4-77 
of RECEIVE_IMMEDIATE verb 4-82 
of REQUEST_TO_SEND verb 4-86 
of SEND_DATA verb 4-87 
of SEND_ERROR verb 4-90 
of TEST verb 4-94 
resources 

conversation 

See conversation resource 
examples of 1-1 
local 1-1 
logical 1-1 
protected 1-4 

See also protected resource 
remote 1-1 

serially reusable 1-3 
state representation of 1-1 
unprotected 1-4, 4-49 
RESPONSIBLE parameter 

of CHANGE_SESSION LIMIT verb 5-6 
of RESET_SESSION_LIMIT verb 5-12 
RETURN_CODE parameter 

of ACTIVATE_SESSION verb 5-19 

of ALLOCATE verb 4-55 

of CHANGE_SESSION_LIMIT verb 5-6 

of CONFIRM verb 4-59 

of DEACTIVATE SESSION verb 5-21 

of DEALLOCATE verb 4-63 

of DEFINE_LOCAL_LU verb 5-24 

of DEFINEJ10DE verb 5-32 

of DEFINE_REMOTE LU verb 5-27 

of DEFINE_TP verb 5-37 

of DELETE verb 5-49 

of DISPLAY_LOCAL_LU verb 5-40 

of DISPLAY_MODE verb 5-45 

of DISPLAY_REMOTE LU verb 5-42 

of DISPLAY_TP verb 5-47 

of INITIALIZE_SESSION LIMIT verb 5-9 
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of MC_ALLOCATE verb 4-5 
of MC_CONFIRM verb 4-8 
of MC_DEALLOCATE verb 4-12 
of MC_PREPARE_TO_RECEIVE verb 4-21 
of MC_RECEIVE_AND_WAIT verb 4-24 
of MC_RECEIVE_IMMEDIATE verb 4-29 
of MC_SEND_DATA verb 4-35 
of MC_SEND_ERROR verb 4-38 
of MC_TEST verb 4-41 
of PREPARE_TO_RECEIVE verb 4-74 
of PROCESS_SESSION LIMIT verb 5-16 
of RECEIVE_AND_WAIT verb 4-78 
of RECEIVE_IMMEDIATE verb 4-82 
of RESET_SESSION_LIMIT verb 5-14 
of SEND_DATA verb 4-87 
of SEND_ERROR verb 4-90 
of SYNCPT verb 4-47 
of TEST verb 4-94 
of WAIT verb 4-50 

return codes for control operator verbs 
ACTIVATION_FAILURE_NO_RETRY 5-51 
ACTIVATION_FAILURE_RETRY 5-51 
ALL0CATI0N_ERR0R 5-51 
ALLOCATION ERROR subcodes 

See ALLOCATION ERROR subcodes 
COMM A N D_R A C E_R E J ECT 5-51 
correlation table 5-54 
LU_M0DE SESSION_LIMIT CLOSED 5-52 
LU_MODE_SESSION_LIMITlEXCEEDED 5-52 
LU M0DE_SESSI0N_LIMIT_N0T_2ER0 5-52 
LU_MODE_SESSION_LIMIT_ZERO 5-52 
LU_SESSION_LIMIT_EXCEEDED 5-52 
OK 5-52 
OK subcodes 

See OK subcodes 
PARAMETER_ERROR 5-52 
REQUEST_EXCEEDS_MAX_ALLOWED 5-53 
RESOURCE_FAILURE_NO_RETRY 5-53 
UNRECOGNIZED_MODE_NAME 5-53 
return codes for conversation verbs 
ALL0CATI0N_ERR0R 4-99 
ALLOCATION_ERROR subcodes 

See ALLOCATION.ERROR subcodes 
BACKED_OUT 4-101 
correlation table 4-105 
DEALLOCATE_ABEND 4-101 
DEALLOCATE_ABEND_PROG 4-101 
DEALLOCATE_ABEND_SVC 4-101 
DEALLOCATE ABEND_TIMER 4-101 
DEALLOCATE_NORMAL 4-101 
FMH_DAT A_N0T_SUPP0RTED 4-101 
HEURISTIC_MIXED 4-101 
MAP_EXECUTION_FAILURE 4-101 
MAP_N0T FOUND 4-102 
MAPPING NOT SUPPORTED 4-102 
OK 4-102 

PARAMETER_ERROR 4-102 
POSTING_NOT_ACTIVE 4-102 
PR0G_ERR0R_N0_TRUNC 4-102 
PR0G_ERR0R_PURGING 4-103 
PROG_ERROR_TRUNC 4-103 
RESOURCE_FAILURE_NO_RETRY 4-103 
RESOURCE_FAILURE_RETRY 4-103 
SVC_ERROR_N0_TRUNC 4-103 
SVC_ERROR_PURGING 4-103 
SVC_ERROR_TRUNC 4-103 
UNSUCCESSFUL 4-104 
RETURN.CONTROL parameter 
of ALLOCATE verb 4-54 
of MC_ALLOCATE verb 4-4 
RETURN statement 3-2 
returned parameters 3-10 




SAME access security 4-4, 4-55 
security 

conversation-level 5-29 
session-level 5-28 
veriflcation, 
conversation-level 5-23 
SECURITY_ACCEPTANCE L0CAL_LU parameter 
of DISPL AY_REMOTE__LU verb 5-43 
SECURITY_ACCEPTANCE parameter 

of DEFINE_REMOTE_LU verb 5-27 
SECURITY_ACCEPTANCE_REM0TE_LU parameter 
of DISPLAY_REMOTE_LU verb 5-43 
SECURITY^ACCESS parameter 
of DEFINE_TP verb 5-36 
of DISPLAY TP verb 5-48 
SECURITY NOT VALID 

See ALLQCATION_ERROR subcodes 
SECURITY parameter 

of ALLOCATE verb 4-55 
of DEFINE_LOCAL_LU verb 5-23 
of DISPLAY_LQCAL_LU verb 5-40 
of MC_ALLOCATE verb 4-4 
SECURITY.PROFILE parameter 

of GET ATTRIBUTES verb 4-69 
of HC_GET ATTRIBUTES verb 4-17 
SECURITY_REQUIRED parameter 
of DEFINE TP verb 5-35 
of DISPLAY.TP verb 5-47 
SECURITYJJSER ID parameter 

of GET_ATTRIBUTES verb 4-69 
of MC_GET_ATTRIBUTES verb 4-17 
send buffer of LU 

accumulating data in 3-2 
See also buffering by LU 
flushing 3-2 

See also flushing LU f s send buffer 
SENDJ0ATA verb 4-87 
$END_ERR0R verb 4-90 
SEND indication 

received by MC_RECEIVE_ANDJ4AIT 
verb 4-25 

received by MC_RECEIVE_IMMEDIATE 
verb 4-30 

received by RECEIVE_AND_WAIT 
verb 4-79 

received by RECEIVE_IMMEDIATE 
verb 4-83 

sent by MC_PREPARE_TO_RECEIVE 
verb 4-22 

sent by MC_RECEIVE_AND_WAIT 
verb 4-24 

sent by PREPARE__TO_RECEIVE verb 4-75 
sent by RECEIVE_AND_WAIT verb 4-77 
SENDJ1AX_RU_SIZE_LGWER_B0UND parameter 
of DEFINE^MODE verb 5-31 
of DISPLAYJ10DE verb 5-45 
SEND MAX_RU_SIZEJJPPER_BOUND parameter 
of DEFINE^MODE verb 5-31 
of DISPLAY_M0DE verb 5-45 
SEND — PACING^WINDOW parameter 
of DEFINE^MODE verb 5-30 
of DISPLAYJ1QDE verb 5-45 
send state 

changing conversation to 

using SEND_ERROR verb 4-90 
changing mapped conversation to 
using MC_$EiSD_ERROR verb 4-38 
of a conversation 4-97 

See also conversation state 
changes 
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requesting change in conversation to* 
using REQUESTJTO_$END verb 4-86 
requesting change in mapped conversa¬ 
tion to 

using MC_REQUEST_TO_SEND 
verb 4-34 

send support of symbol strings C-3 
sending data 

using MC_SEND_DATA verb 4-35 
using SEND_DATA verb 4-87 
sending error notification 

using MC_SEND_ERROR verb 4-38 
using SEND_ERROR verb 4-90 
serially reusable resource 1-3 
session 

See LU-LU session 
session control verbs 5-18 
SESSION_ID parameter 

of DEACTIVATE_SESSION verb 5-21 
SESSION_IDS parameter 

of DISPLAYJ10DE verb 5-46 
SESSION_LEVEL_CRYPT0GRAPHY parameter 
of DEFINEJ10DE verb 5-31 
of DISPLAYJ10DE verb 5-45 
session-level security 5-28 
SINGLETSESSIOH REINITIATION parameter 
of DEFINEJ10DE verb 5-31 
of DISPLAY_MODE verb 5-45 
single sessions 
definition 5-1 

SNA 

See Systems Network Architecture 
(SNA) 

SNA service transaction program 4-52* 
D-l 

CNOS service transaction pro¬ 
gram 5-4, 5-17 

specified by TPN parameter 4-54 
SNASVCMG mode name 

for CNOS conversation 5-4 
on ACTIVATE verb 5-19 
on ALLOCATE verb 4-53 
on INITIALIZE_SESSIONJ.IMIT verb 5-8 
on RESET_SE$SION_LIMIT verb 5-12 
source LU 

definition 5-4 

returned on LU_NAME parameter 5-16 
specification of symbol strings C-3 
state changes 
conversation 

See conversation state changes 
state check 

See ABEND conditions ^ 

state representation of resources 1-1 
states 

conversation 

See conversation states 
STATUS parameter 

of DEFINE^TP verb 5-34 
of DISPLAY_TP verb 5-47 
structure 

protocol boundary 2-2 
transaction program 3-1 
subsetting of verbs 3-8 
supplied-and-returned parameters 3-10 
supplied parameters 3-10 
support of LU 6.2 verbs 
base set 

definition 3-8 
local support 

definition 3-8 
option sets 

definition 3-8 
remote support 


definition 3-9 
support of verbs 

See also base and optional support 
option sets 

descriptions A-l 

SVC_ERR0R_N0_TRUNC return code 4-103 
SVC_ERRQR_PURGING return code 4-103 
SVC_ERROR_JRUNC return code 4-103 
symbol string 

conventions C-l 
length C-l 
type C-l 

SYNC_LEVEL_NOT_SUPPORTED_BYJ.U 
See ALLOCATION.ERROR subcodes 
SYNC_LEVEL_NOT_SUPPORTED_BY_PGM 
See ALLOCATIQN_ERR0R subcodes 
SYNC_LEVEL parameter 

of ALLOCATE verb 4-54 
of DEFINE_TP verb 5-35 
of DISPLAYJ10DE verb 5-45 
of DISPLAY_TP verb 5-47 
of GET_ATTRIBUTES verb 4-68 
of MC ALLOCATE verb 4-4 
of MC~GET_ATTRIBUTES verb 4-16 
SYNC LEVEL_SUPPORT parameter 
of DEFINEJ1QDE verb 5-31 
sync-point request 

received by MC_RECEIVE_AND_WAIT 
verb 4-26 

received by RECEIVE_AND_WAIT 
verb 4-79 

received by RECEIVE_IMMEDIATE 
verb 4-84 

sent by SYNCPT verb 4-47 
sync-point service 1-4 
sync point state 

of a conversation 4-97 

See also conversation state 
changes 

synchronization level 

changing conversation to receive 
state based on 4-73 
changing mapped conversation to 
receive state based on 4-20 
deallocating conversation based 
on 4-62 

deallocating mapped conversation 
based on 4-11 
for conversation 4-54 
for mapped conversation 4-4 
SYNCPT synchronization level 4-4, 4-54 
SYNCPT verb 4-47 

Systems Network Architecture (SNA) 1-1 


CD 


TAKE_SYNCPT_DEALLOCATE indication 
received by MC_RECEIVE_AND_WAIT 
verb 4-26 

received by MC_R EC El VE_I IMMEDIATE 
verb 4-31 

received by RECEIVE_ANDJ4AIT 
verb 4-79 

received by RECEIVE_IMMEDIATE 
verb 4-84 

TAKE_SYNCPT indication 

received by MC_RECEIVE_AND_WAIT 
verb 4-26 

received by MC_RECEIVE_IMMEDIATE 
verb 4-30 
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received by RECEIVE.AND.WAIT 
verb 4-79 

received by RECEIVE.IMMEDIATE 
verb 4-84 

TAKE.SYNCPT.SEND indication 

received by riC_RECEIVE.AND.WAIT 
verb 4-26 

received by MC.RECEIVE.IMMEDIATE 
verb 4-31 

received by RECEIVE.AND.WAIT 
verb 4-79 

received by RECEIVE.IMMEDIATE 
verb 4-84 
target LU 

definition 5-4 

specified by LU.NAME parameter 5-5 
TERMINATION.COUNT parameter 
of DISPLAY.MODE verb 5-46 
test for posting 

using MC.TEST verb 4-41 
using TEST verb 4-94 
test for REQUEST.TO.SEND notification 
using MC.TEST verb 4-41 
using TEST verb 4-94 
TEST parameter 

of MC.TEST verb 4-41 
of TEST verb 4-94 
TEST verb 4-41, 4-94 
TP.NAME parameter 

of DEFINE.TP verb 5-34 
of DELETE verb 5-49 
of DISPLAY.TP verb 5-47 
TP.NAMES 

of DISPLAY.LOCAL.LU verb 5-40 
TPN.NOT.RECOGNIZED 

See ALLOCATION.ERROR subcodes 
TPN parameter 

of ALLOCATE verb 4-54 
of MC.ALLOCATE verb 4-3 
TRANS.PGM.NOT.AVAIL NO.RETRY 

See ALLOCATION.ERROR subcodes 
TRANS.PGM.NOT AVAIL.RETRY 

See ALLOCATION.ERROR subcodes 
transaction 

definition 1-1 

distributed processing of 1-2 
example 1-1 
transaction program 
abnormal ending 

See ABEND conditions 
application 4-2, 4-44 
control-operator 5-1 
defining operating parameters 
for 5-34 
definition 1-2 

displaying operating parameters 
for 5-47 
example 1-2 
execution 3-1 
instance 3-1 

LU services component 4-52 
name 

carried in allocation request 3-1 
specified by TPN parameter 4-3, 
4-54 

other program statements of 3-1 
SNA service 4-52, D-l 
structure 3-1 
verbs 3-1 

See also verbs 
truncated data record 

received by MC.RECEIVE_AND.WAIT 
verb 4-25 


received by MC.RECEIVE.IMMEDIATE 
verb 4-30 
truncated LL field 

indicated on RECEIVE.AND.WAIT 
verb 4-79 

indicated on RECEIVE.IMMEDIATE 
verb 4-83 

truncation of logical records 
by SEND.ERROR verb 4-92 
return codes indicating 4-103 
two-way alternate data transfer 3-2, 
1-3 

type-independent conversation 
verbs 4-44, 3-4, 4-44 

See also individual verbs 
TYPE parameter 

of ALLOCATE verb 4-54 
of DEACTIVATE.SESSION verb 5-21 
of DEALLOCATE verb 4-62 
of GET.TYPE verb 4-46 
of MC.DEALLOCATE verb 4-11 
of MC.PREPARE.TO.RECEIVE verb 4-20 
of PREPARE.TO.RECEIVE verb 4-73 
of SEND.ERROR verb 4-90 
types of symbol strings C-l 


CD 

UNINTERPRETED LU_NAME parameter 
of DEFINE_REMOTE_LU verb 5-26 
of DISPLAY_REMOTE_LU verb 5-42 
unprotected resources 4-49 
UNREC0GNIZED_M0DE_HAME return code 
for control operator verbs 5-53 
UNSUCCESSFUL return code 4-104 


verb 

ending semicolon 3-10 
format box 3-10 
name 3-10 
parameters 

bracketed 3-10 
returned 3-10 
supplied 3-10 
supplied-and-returned 3-10 
verb description format 3-9 
verbs 

ABEND conditions 

See ABEND conditions, for LU 6.2 
verbs 

base and optional support 

See base and optional support 
base set of 3-8 
basic conversation 

See also basic conversation verbs 
examples of use B-l 
categories of 3-3 
control-operator 

See control-operator verbs 
conversation verbs 

See conversation verbs 
execution of 3-2 
format for describing 3-9 
issued by transaction program 3-2 
LU services programs use of 4-52 
mapped conversation 


Index 


X-ll 



See mapped conversation verbs 
optional sets of 3-8 
overview description of 3-3 
overview descriptions 3-3 
product-support subsets of 3-8 
syntax description of 3-9 
transaction program 3-1 
type-independent conversation 

See type-independent conversation 
verbs 
verification 

conversation-level security 5-23 
list 5-23 

resource access 5-35 




WAIT verb 4-50 
waiting for information 

using MC_RECEIVE ANDJ4AIT verb 4*24 
using RECEIVE AND_WAIT verb 4-77 
WHAT_RECEIVED parameter 

of MC_RECEIVE_AND_WAIT verb 4-25 
o.f MC_RECEIVE_IMMEDIATE verb 4-30 
of RECEIVE_AND_WAIT verb 4-78 
of RECEIVEIMMEDIATE verb 4-83 
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